couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Mon, 29 Dec 2008 15:10:06 GMT
With respect to a meta structure, I was going to make this comment  
yesterday as I think Geir was arguing for this:

It seems to me that occam's razor argues for the simplicity of a  
single JSON doc, rather that a "metadoc" envelope that contains  
another JSON doc embedded in it. It's not clear to me that creating  
this separation of concerns buys anything at all. The use of an  
underscore to designate distinguished fields at the top level is a  
fairly easy convention to get your arms around. It also provides a  
nice convention for extensions, .eg. "_external". Does it blur the  
distinction between data and metadata, yes but I think that's a good  

Perhaps it's useful to turn the argument around and ask what having a  
separate metadoc buys you? You now presumably store the unique id in  
one JSON fragment and the actual doc in another, how does this  
simplify the code?

I guess I'm not a big fan of metadata

On Dec 29, 2008, at 9:21 AM, Damien Katz wrote:

> Yes, it is perfectly clear to a newbie, because it's the simplest  
> case. That's why I coded it this way initially, it seemed simpler.
> 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.
> -Damien
> On Dec 29, 2008, at 8:58 AM, Geir Magnusson Jr. wrote:
>> That rule would have been perfectly clear to me as a newbie.
>> +1
>> geir
>> On Dec 29, 2008, at 8:55 AM, Antony Blakey wrote:
>>> On 29/12/2008, at 11:11 PM, Damien Katz wrote:
>>>> The problem was there where other reserved fields in documents  
>>>> that started with underscore, but in other places the fields  
>>>> wouldn't have an underscore. Keep track of which fieldname had  
>>>> underscores and where became confusing. The rule was changed to  
>>>> be simpler to understand and deal with.
>>> A simpler rule is: _rev is the name no matter where it appears,  
>>> same with _id. I'd go so far as say that this kind of rule is so  
>>> fundamental to our idea of identity and naming, that it doesn't  
>>> even count as a rule. And there had better be a really good  
>>> reason to introduce a rule contrary to such an strongly implicit  
>>> and intrinsic concept.
>>> And as far as 'Keeping track of which fieldname had underscores",  
>>> it would seem that the current situation is the worst, because  
>>> you have to keep track not based on identity e.g. _rev and _id,  
>>> but rather on context, which is a dynamic and more intellectually  
>>> demanding concept than semantic identity. Furthermore, in this  
>>> scheme, names must be mapped under structural transformation  
>>> (such as copying the _id and _rev fields from one context to  
>>> another), which complicates generic transformations.
>>> IMO the name isn't "rev" with sometimes an underscore, rather the  
>>> name IS "_rev". Same with "_id".
>>> A single name for a concept, lexically consistent, is less  
>>> cognitive load both initially and on an ongoing basis.
>>> Antony Blakey
>>> -------------
>>> CTO, Linkuistics Pty Ltd
>>> Ph: 0438 840 787
>>> The ultimate measure of a man is not where he stands in moments  
>>> of comfort and convenience, but where he stands at times of  
>>> challenge and controversy.
>>> -- Martin Luther King

View raw message