couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Couchdb Wiki] Update of "SchemaForToDoList" by JensAlfke
Date Sat, 06 Aug 2011 19:21:50 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "SchemaForToDoList" page has been changed by JensAlfke:

New page:
= Proposed Schema For To-Do Lists =
Created by JensAlfke on 6 Aug 2011

== Introduction ==

The to-do list seems like a good use case for CouchDB: it's got a fairly well-defined data
format; queries are pretty straightforward; it's a very popular type of application; and transparent
syncing is a crucial feature.

By defining a standard base data schema for applications to use, they can easily interoperate
on a single data store, even if some apps add extra metadata.

=== Applications ===

Some apps I looked at, and/or have used myself:
 * [[|Things]]
 * [[|OmniFocus]]
 * [[|RememberTheMilk]]
 * [[|Wunderlist]]
 * [[|Producteev]]

== Feature Set ==

=== Level 0: Required ===

The essential features of a to-do list are very simple. We need a set of items with the following

 * Title
 * Completed, aka Checked

That's it, really. Couchbase's current mobile demo app has only these features, and it's actually
useful in the real world. 

=== Level 1: Common ===

When you look at real to-do list apps, they all have many of the following extra features:

 * Star / Flag, or a range of priorities
 * Creation Date
 * Due Date (optional)
 * Notes
 * URL Link
 * Tags
 * Multiple named lists, where each item can be in one list at a time.
 * Hierarchies of lists
 * File attachments

=== Level 2: Advanced ===

Some extra features found in higher-end list apps:

 * Custom re-ordering of items in a list
 * Hierarchies of items
 * Recurring tasks that respawn on a schedule (weekly, first Tuesday of the month, etc.)
 * Percent complete
 * Estimated time
 * Reminders at some interval before the due date

I'm not going to address these here. Maybe in a future update to this spec.

== Document Schema ==

=== Item ===

 * "type": "todo", required
 * "title": string, required
 * "check": boolean, defaults to false
 * "priority": boolean or number, defaults to false
 * "created_at": date-time*
 * "modified_at": date-time [not necessarily visible to the user, but useful in conflict resolution]
 * "due_at": date or date-time
 * "notes": string
 * "link": string [a URL]
 * "category": string, defaults to "INBOX" [name of list this is in]
 * "tags": array

* Dates and times are specified in ISO-8601 format, which appears to be the de-facto standard
used in JSON. A "date" doesn't contain the time portion of the string. Times should all be
given in GMT to allow for easy sorting via collation.

File attachments can be stored as, well, attachments. No need to define a specific schema
for them.

=== Category ===

For the most part the list of categories can be derived from the union of the "category" values
of all "todo" items; but that implies that categories with no items in them cease to exist,
which isn't good! Defining an explicit document type also leaves open the option of adding
metadata to categories in the future (e.g. colors or descriptions.)

 * "type": "category", required
 * "name": string, required
 * "parent": string

It's not necessary for every category to have its own "category" document. In other words,
the application's UI should show a category for every unique "category" value that appears
in a "todo" document, whether or not there's a "category" document for it. Otherwise a list
item can disappear from the UI if its category document is renamed without updating its "category"
value, which can happen during replication.

''Question:'' Should we instead use a more normalized relation, where the todo item's "category"
value is the _id of its category document? On the plus side, this allows renaming a category
without having to update every item in it. On the minus side, it could cause problems when
merging. (For example: on one device I add an item to a category, and on another device I
delete that category. After syncing I'm left with an item pointing to a nonexistent category

View raw message