No, and I'll claim it's my fault, as I haven't finished the spec yet.
(I was writing it...)
But I want some Python drivers, to the point where I'm willing to pay
for them :)
geir
On Dec 28, 2008, at 10:47 PM, paul jobs wrote:
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....}
}
