http://www.mongodb.org/Drivers Geir no python drivers
On 12/28/08, Geir Magnusson Jr. <[email protected]> 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....} > } > >
