incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
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. <geir@pobox.com>  
> 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


Mime
View raw message