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....}
}
