couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Mon, 29 Dec 2008 13:50:11 GMT
If the metadata was separate from the "user data" everywhere, as it is  
in view results,  the problem just simply goes away. But I realize  
that won't be the solution.  :)

My $0.02 as a new user - I think I agree with Jan here - consistency  
is important.

I started really learning about CouchDB yesterday, so my memory of the  
"journey" is clear, and the "special fields" thing did throw a WTF  
exception... not because of the existence of _id and _rev in user data  
(that threw the "OhGeeze..." exception), but because they were  
inconsistently handled and presented in basic things like _all_docs/

The start of my thread yesterday ("newbie question #1") was really  
about that - why "id" *and* "_id",  "rev" *and* "_rev", how the  
presence of "key" in _all_docs/ seems to be a leak from how views  
work, why are view results so different than document results (e.g.  
why you don't inject _rev, _id_ and key into the data part of the  
view, why view/all is different format than db/_all_docs/...)

I do understand that as codebases evolve, APIs are going to change,  
and when it's OSS, you always accrete users depending on "whatever is  
there", so change is hard.

But this could be solved by versioning the API -  put something in a  
standard place in the URI to indicate that it's not the current API e.g.

  GET v1/somedatabase/_all_docs

and this gives you the chance offer other APIs (like one for us  
crackpots that insist that implementation metadata doesn't belong in  
the user data :)

Dunno.  Haven't used CouchDB in anger yet, so take all this w/ a grain  
of salt, but all my observations and what I hope are taken as  
constructive criticisms notwithstanding, I really am excited about  
CouchDB.

geir


On Dec 29, 2008, at 8:14 AM, Jan Lehnardt wrote:

>
> On 29 Dec 2008, at 13:41, Damien Katz wrote:
>
>> I disagree we should change this back. I don't know if anyone  
>> remembers, but this is how I implemented long ago in the first  
>> versions of the post-XML CouchDB. 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. If it's  
>> in the root of a doc and it starts with underscore, it's reserved.  
>> You don't see the reserved underscore fields anywhere else, only in  
>> document top level.
>
> My issue with this is when learning about CouchDB, documents come  
> first and the "special fields are prefixed with an underscore" rule  
> is taken up naturally. Later with views and query parameters, this  
> rule is broken. You could argue that when we teach documents, we  
> should make the actual rule more explicit and that is certainly  
> true, but we don't control the ways people pick up CouchDB. We  
> control the API however and are able to reduce WTF-factors.
>
>
>> -Damien
>>
>>
>> On Dec 28, 2008, at 2:21 PM, Jan Lehnardt wrote:
>>
>>>
>>> On 28 Dec 2008, at 14:32, Antony Blakey wrote:
>>>
>>>>
>>>> On 28/12/2008, at 11:56 PM, Paul Davis wrote:
>>>>
>>>>> Why "id" and "rev" are used instead of "_id" and
>>>>> "_rev" I couldn't really tell you. I hate to say "historical  
>>>>> reasons"
>>>>> but I'm guessing that when Damien designed the view output he just
>>>>> labeled then "id" and "rev" without the underscore because it's  
>>>>> not
>>>>> needed to distinguish from the rest of the doc.
>>>>
>>>> Desirable to change that (and any other inconsistencies) before a  
>>>> 1.0
>>>
>>> This keeps coming up and I've been advocating this for a while now:
>>>
>>> +1 for changing view result rows `rev` to `_rev` to avoid confusion.
>>>
>>> CC'ing dev@c.a.o.
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>
>>
>


Mime
View raw message