couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: newbie question #1
Date Sun, 28 Dec 2008 15:45:10 GMT

On Dec 28, 2008, at 10:10 AM, Paul Davis wrote:

> On Sun, Dec 28, 2008 at 9:50 AM, Geir Magnusson Jr. <>  
> 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


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  

Thanks for the discussion.


View raw message