On Dec 28, 2008, at 8:26 AM, Paul Davis wrote:
On Sun, Dec 28, 2008 at 8:12 AM, Geir Magnusson Jr. <[email protected]>
wrote:
[SNIP]
Also check out http://planet.couchdb.com for related blog posts. I
also find a google alert for CouchDB to be pretty useful.
Thanks
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 :)
You're pretty much spot on here. "id" and "key" both refer to the
"_id" field in a document. And the "rev" does indeed refer to the
"_rev" attribute. Why "id" and "rev" are used instead of "_id" and
"_rev" I couldn't really tell you. I hate to say "historical reasons"
but I'm guessing that when Damien designed the view output he just
labeled then "id" and "rev" without the underscore because it's not
needed to distinguish from the rest of the doc.
Ok, cool. So... can key be something else? Or should I assume that
"key" is a synonym for "_id"?
[SNIP]
{
_id : whatever
_rev : whatever
doc : { ..... the full user document that can have _id, _rev and
whatever....}
}
Like Noah says, reserving underscore prefixed fields as private to
CouchDB doesn't make it not JSON. I'd argue that putting the document
stuff inside a doc member would probably be a annoyance in that every
operation on the doc would require doc.doc.foo instead of just doc.foo
I certainly understand that there are tradeoffs. We do the same thing
at 10gen - modify the user's document for storage. Some random
thoughts :
1) doing an insert requires that the user document be deserialized
(maybe only partially?), the additional fields inserted, and then re-
serialized for storage. Have a metadata envelope means that the user
document keyspace and the server's metadata keyspace are totally
decoupled.
2) It prevents, or at least makes harder, any document security - any
hash function would have to account for the fact that there may be
external keys injected into the document ("_*"). This is doable, but
now makes your code - which was handling "generic JSON" - now have to
know that it's working w/ a couchdb store....
3) the doc.doc.foo problem - Is that really a problem? I haven't
worked w/ couch yet to understand the common access patterns, but it
seems that the different calls to the rest API return things of
different "shape" anyway... if you are accessing by document id, you
could just get the user doc back, and it seems that other queries
return metadata anyway (e.g. _all_docs) so people must be used to
pulling the user doc out of the framing data.... You could solve the
issue in MR easily as well.
Anyway, I don't want this to distract :) It's just a subject I'm
interested in, as it's a personal pet peeve...
geir
HTH,
Paul Davis
