couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric casteleijn <>
Subject Re: Best practice: adding an app specific chunk to a document
Date Fri, 07 Aug 2009 14:48:06 GMT
Justin Walgran wrote:
> I'm building a couch app that works with it's own database of
> documents or as an add-in to any existing database of documents. In
> the case where the app is added to an existing database, I would like
> to scan the documents and add a little "meta" section to each one for
> storing information relevant to the app. I am very excited by the idea
> of "mix in" applications, but this raises a few questions:
> Is it wrong to "pollute" the existing documents with my extra meta section?
> Are there any thoughts on the best value to use as a key for my data
> section to minimize collisions? Is a single master GUID my only
> choice?
> Thanks for the feedback.

You might want to check out the way desktopcouch[1] does this: One of 
the intented use cases of desktopcouch is exactly to make databases 
usable by multiple applications that are interested in the same domain. 
(For instance a contacts database that could be used by email 
applications and IM applications and any other application that would 
need to communicate things with other people.)

We've decided to have things that all applications agree on as a top 
level field in the document, described by a schema (so a contact would 
have first_name and last_name, and some other fields that every 
application would conceaivably be interested in) and then there is a 
dictionary called 'application_annotations' where each application has 
its own namespace in which it can store application specific data, or 
data that not all applications agree on.

This is a flexible way to do things in that it doesn't impose a lot on 
applications that work with it (you don't *have* to look at 
application_annotations if you don't need it, all we ask is that you 
don't delete it) and it makes complicated use cases possible.


- eric casteleijn

View raw message