couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ara.t.howard" <>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Mon, 29 Dec 2008 16:53:29 GMT

On Dec 29, 2008, at 1:50 AM, Christopher Lenz wrote:

> I think this is the wrong direction. If these naming issues really  
> are generating substantial confusion (which I doubt), we should  
> rather be looking into changing the mechanism for including meta- 
> information with documents so that the leading underscores could be  
> dropped across the board. Maybe something like:
>  {
>    "_meta": {
>      "id": "foo",
>      "rev": "1234"
>    },
>    "title": "Foo",
>    ...
>  }
> This would also cause client breakage, but at least we wouldn't be  
> scattering more underscores around the API.

i must say i mostly agree with geir and support the above style whole  
heartedly.  it would simplify writing client libraries *massively*.   
currently client code will end up looking like

   if doc['_rev']

   if doc['_id']

for instance

cfp:~/src/git/couchrest > grep _id lib/couchrest/core/model.rb |grep  
       unless self['_id'] && self['_rev']
     # Removes the <tt>_id</tt> and <tt>_rev</tt> fields, preparing

and this will only get more confusing as time goes on and the number  
of metadata fields increases.  it's a PITA for couch libs  to have to  
track these changes over time and seriously hampers forward/backwards  
compat, practically ensuring migration issues for each and every  
client lib and document stored.

the beauty of '_meta' (as above - and although i'd propose simply '_')  
is that it minimally but completely represents the concept couch docs  
need to express which is simply that "there will be meta data in the  
doc."  occam's razor alone should be proof that this is the best  
method of piggybacking that inside a couch/json doc.

one thing people haven't seem concerned with is that of meta data  
being flat: it seems quite likely that, over time, metadata in docs  
would evolve to have trees of information and in that case the current  
rules will lead to slightly ugly structures with required leading  
underscores at the root but optional ones after.

another thing which is entirely imaginable is some sort of server side  
merge operation which couch's current metadata scheme cannot handle.   
for instance if you ever had to merge

   { '_id' : 1, 'value' : 40 }
   { '_id' : 2, 'value' : 42 }

you'd have to do something like

   { '_id1' : 1, '_id2' : 2 }

but a '_' scheme could simply return one metadata element per doc in  
an array

   { '_' : [ metadata1, metadata2 ] }

or any other nested structure without needing to pollute the top  

there are actually *many* precedents for moving towards a single _meta/ 
_ key in repos out there, rails' handling of options in methods  
springs to mind.  they started out doing things like

   some_method options = {}

where certain keys would be skimmed out from options and the rest  
passed through to be, for instance, html attributes or some such but  
increasingly they are moving towards signatures like

   some_method :key => :value, :html => {:id => 'foo', :class => 'bar'}

because mixing the semantics of keys in a single hash leading to  
spaghetti code, both in core and client, as the process of accretion  
takes hold.

anyhow, my 2cts is that the current rules for couch are fairly simple,  
but they can in fact be, and forever remain, an both an order of  
magnitude simpler and completely consistent.

a @
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama

View raw message