incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject newbie question #1
Date Sun, 28 Dec 2008 13:12:10 GMT
I work for a company (10gen) that's making what I refer to as a  
"document oriented" database (called MongoDB*), and I've long been  
meaning to grok CouchDB.  Now that I have some time during the year- 
end hibernation, I figured this is a good time to dig in.

So I have some basic questions.  Warning - these are really basic, and  
could be caused entirely by my current lack of caffination.  I assume  
the best place to find docs is the wiki.  If there's something better,  
any pointers welcome.

First newbie question :

Looking at, 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 :)


I put these notes at the bottom as they are asides...

* MongoDB - I'm getting a "community" site going (http:// indep of our corp site (  It's  
open source, written in C, and has some very nice features.

** I've had this debate internally at 10gen too, and I'm not  
interested in picking a fight here :)  I think that by reserving  
fields like this, you can't claim to be storing JSON anymore, but  
"JSON--" or "almost JSON".   I think that a better way to do this is  
provide a JSON-based "envelope" for documents in which the database  
reserves all fields, and the user document is "hung" in there on one  
of them.  This allows adding metadata over time free of collision with  
the user documents :

      _id : whatever
      _rev : whatever
      doc : { ..... the full user document that can have _id, _rev and  

View raw message