couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Mon, 29 Dec 2008 19:32:41 GMT
On Mon, Dec 29, 2008 at 6:21 AM, Damien Katz <> 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

Chris Anderson

View raw message