incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul jobs" <webjog...@gmail.com>
Subject Re: newbie question #1
Date Mon, 29 Dec 2008 03:47:30 GMT
http://www.mongodb.org/Drivers
Geir no python drivers


On 12/28/08, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> 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 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 :)
>
> geir
>
>
>
>
>
> I put these notes at the bottom as they are asides...
>
> * MongoDB - I'm getting a "community" site going (http://www.mongodb.org)
> indep of our corp site (http://www.10gen.com/).  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
> whatever....}
>  }
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message