On Dec 28, 2008, at 10:10 AM, Paul Davis wrote:
On Sun, Dec 28, 2008 at 9:50 AM, Geir Magnusson Jr. <[email protected]>
wrote:
On Dec 28, 2008, at 9:36 AM, Damien Katz wrote:
On Dec 28, 2008, at 8:58 AM, Geir Magnusson Jr. wrote:
The following two documents are legal JSON documents, but CouchDB
can't
store them (if I grok CouchDB right) :
{
"_id" : "geir's document",
"foo" : "bar"
}
{
"_id" : "geir's document",
"foo" : "woogie"
}
Sure you can:
{_id:"the actual id",
body:{
"_id" : "geir's document",
"foo" : "bar"
}
}
If you need to store underscore fields, store move the whole
document down
from the top level into another field.
I understand that, but that's really my point - I need to change my
document
if I want to store it in CouchDB. People don't seem to care
though :)
I think the stumbling block here is that we're using two different
definitions of 'document'. You appear to consider the user data a
document where as CouchDB terminology refers to the entire JSON object
as the document. Thus if for the sake of your application, document
referred to the 'user document' as the data stored under a specific
element, the whole issue goes away.
Yes, that's probably a good way to describe it - difference in
perspective, I think.
From my perspective as someone that wants to store and retrieve
documents, the REST API is darn elegant. In fact, why should I know
that there's CouchDB there? All I know is that I'm hitting a URL to
get a document. It strikes me *as a user* as cleaner if
http://whatever/db/id
returns the JSON that I put in there, nor do I have to worry what is
in my doc. _id and _rev are store-specific housekeeping that I just
don't necessarily care about. Of course, I should be able to get
them, I suppose.
I guess I need to play more, and see when I'm fetching a specific
document, how useful it is to have the _rev and _id embedded in the
doc itself. That will help me understand.
I do wonder if a standard "JSON Persistence Format" could be agreed
upon so that internal, implementation-specific housekeeping things
(like _id and _rev) can be kept separate from the user's data in a
uniform way, so that multiple approaches to JSON persistence can be
developed while still being somewhat uniform for developers to work
with.
Thanks for the discussion.
geir
