Proposed Schema For To-Do Lists

Created by JensAlfke on 6 Aug 2011


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.


Some apps I looked at, and/or have used myself:

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 properties:

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:

Level 2: Advanced

Some extra features found in higher-end list apps:

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

Document Schema


* 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.


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.)

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 _id.)