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.
[1] https://code.launchpad.net/desktopcouch
http://www.freedesktop.org/wiki/Specifications/desktopcouch
--
- eric casteleijn
https://launchpad.net/~thisfred
http://www.canonical.com
