couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: newbie question #1
Date Sun, 28 Dec 2008 13:47:10 GMT

On Dec 28, 2008, at 8:26 AM, Paul Davis wrote:

> On Sun, Dec 28, 2008 at 8:12 AM, Geir Magnusson Jr. <geir@pobox.com>  
> wrote:

[SNIP]
>
> Also check out http://planet.couchdb.com for related blog posts. I
> also find a google alert for CouchDB to be pretty useful.
>

Thanks


>> First newbie question :
>>
>> Looking at http://wiki.apache.org/couchdb/HTTP_Document_API, I  
>> understand
>> that _id and _rev are reserved fields in the document**.  Now,  
>> looking at
>> the _all_docs example, I see I get back a list of docs :
>>
>> {
>> "total_rows": 3, "offset": 0, "rows": [
>>   {"id": "doc1", "key": "doc1", "value": {"rev": "4324BB"}},
>>   {"id": "doc2", "key": "doc2", "value": {"rev":"2441HF"}},
>>   {"id": "doc3", "key": "doc3", "value": {"rev":"74EC24"}}
>> ]
>> }
>>
>> what is "id"?  is that supposed to be "_id"?  what is "key"?  I see  
>> that in
>> futon as well - how does it relate to "_id" or "id" for that  
>> matter?  Also,
>> I assume that "rev" is the "_rev" of the document.  Why not make it  
>> "_rev"?
>>
>> I'm guessing that "id" is "_id", as I can see similar things in the  
>> PUT
>> example, but I guess then the question changes to why not just be  
>> consistent
>> and use "_id" everywhere, especially since I'm allowed to use "id"  
>> in my
>> document?
>>
>> I'm sorry if this is a stupid question - I just don't understand.   
>> I'm happy
>> to update the wiki when I understand :)
>>
>
> You're pretty much spot on here. "id" and "key" both refer to the
> "_id" field in a document. And the "rev" does indeed refer to the
> "_rev" attribute. 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.

Ok, cool.  So... can key be something else?  Or should I assume that  
"key" is a synonym for "_id"?

[SNIP]

>> {
>>    _id : whatever
>>    _rev : whatever
>>    doc : { ..... the full user document that can have _id, _rev and
>> whatever....}
>> }
>>
>>
>
> Like Noah says, reserving underscore prefixed fields as private to
> CouchDB doesn't make it not JSON. I'd argue that putting the document
> stuff inside a doc member would probably be a annoyance in that every
> operation on the doc would require doc.doc.foo instead of just doc.foo

I certainly understand that there are tradeoffs.  We do the same thing  
at 10gen - modify the user's document for storage.  Some random  
thoughts :

1) doing an insert requires that the user document be deserialized  
(maybe only partially?), the additional fields inserted, and then re- 
serialized for storage.  Have a metadata envelope means that the user  
document keyspace and the server's metadata keyspace are totally  
decoupled.

2) It prevents, or at least makes harder, any document security - any  
hash function would have to account for the fact that there may be  
external keys injected into the document ("_*").  This is doable, but  
now makes your code - which was handling "generic JSON" - now have to  
know that it's working w/ a couchdb store....

3) the doc.doc.foo problem - Is that really a problem?  I haven't  
worked w/ couch yet to understand the common access patterns, but it  
seems that the different calls to the rest API return things of  
different "shape" anyway...  if you are accessing by document id, you  
could just get the user doc back, and it seems that other queries  
return metadata anyway (e.g. _all_docs) so people must be used to  
pulling the user doc out of the framing data....  You could solve the  
issue in MR easily as well.

Anyway, I don't want this to distract :)  It's just a subject I'm  
interested in, as it's a personal pet peeve...

geir


>
>
> HTH,
> Paul Davis


Mime
View raw message