On Mon, Dec 29, 2008 at 6:21 AM, Damien Katz <[email protected]> wrote: > > What isn't immediately obvious is all the other special fields that can > appear in documents and in other contexts. How to make that consistent? I > tried, but couldn't keep it simple. The problem was special names in various > structures no longer have a simple rule to follow, but instead you must know > if this field appears in a document at any time, then it starts with > underscore in other structures. > > The current rule maybe not the most intuitive to a newbie, but it is far > more consistent and easier to work with then when using the deeper APIs. The > only 2 other workable solutions I see is to either stuff everything special > into a _meta structure or only use HTTP headers for all CouchDB meta > information. But after having spent much time thinking about this issue, I > think the current rule is the better compromise. >
I've got to say I agree with Damien and Christopher Lenz on this one. Prefixing "id" and "rev" with "_" in query params and in view rows just seems silly to me. The current rules, where document fields like "_attachments" have special meaning in CouchDB, seems simplest in the long run. The "_" is used to qualify namespace, not name a field. This convention is reused in CouchDB, for non-docid paths, such as _view and _all_docs. Once you understand why the current system is built as it is, the namespace conventions are perfectly clear. I can see the appeal of a single reserved "_meta" field, which contains CouchDB bookkeeping data, but I think it could also turn out to be a step in the wrong direction. _id and _rev are meant to be brittle: that is, changing them on a document, once they are present, means you have stepped outside the CouchDB semantics. Putting them in a _meta group might encourage aggregation and manipulation of the bookkeeping metadata separately from the document, which to me sounds like a recipe for trouble. A "_meta" field would also be an inappropriate place to put "_attachments". I'm not particularly sympathetic to arguments that it's harmful to reserve top-level fields that begin with "_". Just put your data in a doc.actually_the_data field, if you need field names that start with underscore. -- Chris Anderson http://jchris.mfdz.com
