couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dean Landolt" <>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Mon, 29 Dec 2008 17:41:21 GMT
On Mon, Dec 29, 2008 at 11:53 AM, ara.t.howard <>wrote:

> 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 _rev
>      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 namespace
> 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.

I tend to agree that the rules are damn simple now but with time and the
possible buildup of meta cruft, they could get pretty complicated pretty
fast. Of course, given the lore around here that Damien has this thing
designed in his head all the way through 2.0, I think it's a safe bet
metadata would remain fairly stable for some time to come.

Still, just to throw my two pence in, my company's been working quite a bit
with MarkLogic (in spite of my many objections) and their handling of
metadata is pretty flexible. As an xml db, everything's, of course, xml, but
the principles remain -- metadata, or properties in their parlance, are
entirely separate from the actual documents, but reside at the same uri.
There are special api hooks to get at the properties (which I think is
pretty weak, and wouldn't work for couch anyway), but what's sexy is that
since the properties docs are just xml, you can tack on your own properties
all you want, including nesting them, and get at them through the apis or
along a specially-exposed xpath axis. They just reserve a few properties of
their own that you can't step on, but otherwise you can hook into their
metadata facilities in a very flexible way.

While this kind of ultimate flexibility may not be necessary for couch --
given the nature of json docs they have no trouble expressing their
properties inline -- it could certainly be helpful to maintain app-level
housekeeping without polluting the documents themselves. So the notion of
just one reserved attribute, be it "_meta" or "_" or whatever, would be a
perfectly serviceable solution that could yield a few benefits down the
road, like the ability to pass in your own _meta objects (so long as your
attributes don't begin with '_', for instance, reserving these for future
couch properties). So inside _meta (or whatever) _id can become id (because
it's user-definable) and _rev stays _rev (unless that should be definable as
well) and everything else falls into place (except for the massive overhaul
that will probably be needed in the core...ouch!)...

Then just like include_docs there could be an include_meta, or some such, to
offer a more efficient way to get at important data in the view apis without
yanking in the whole doc, or it could just be included by default like it is
now, just in a _meta envelope. It could also help facilitate plugins,
offering a doc-level place for info about, but not part of, a doc (which is
pretty much the embodiment of metadata).

Just a thought...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message