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 the
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.
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
