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: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Fri, 02 Jan 2009 12:13:14 GMT

On Jan 1, 2009, at 9:14 PM, Flinn Mueller wrote:

> On Jan 1, 2009, at 8:24 PM, Geir Magnusson Jr. wrote:
>
>> I know I can do that.  And if CouchDB is the only "JSON source"  
>> that my apps are talking to, then that's fine - all apps can be  
>> written to expect that "schema".
>>
>> But I'm taking a different POV - where a "schema" exists outside of  
>> my app (a pseudo-standard defined by someone else) and I want to  
>> use CouchDB as a source of documents that conform to that schema.   
>> My apps should be able to consume documents in that "JSON schema"  
>> that are sourced from CouchDB, a httpd server returning static  
>> documents, some servlet app running in Tomcat, some .NET thingy, etc.
>>
>> Once you force me to store documents in a new format in order to  
>> protect data in my document that clashes w/ the server's metadata  
>> by sticking the document of interest in a top-level field :
>
>
> Isn't this any issue with any data store?  It's established that _id  
> is arbitrary just like it could be in just about any other data  
> store.  If this is a problem in couchdb it's a problem for you in  
> any data store isn't it?

If the data store chooses to inject it's metadata into my document,  
yes it will be, and that's my point.

>
>
>
>> {
>>   _rev : ...
>>   _id : ...
>>   mydata : { ... the real document ... }
>> }
>>
>> then I think that CDB loses something in terms of being a general  
>> JSON document store.
>
>
>
> You're looking at couchdb's document as if it's your JSON document.   
> It's couchdb's document and it happens to be JSON.

Exactly. That is what I note below - that CDB isn't a "general JSON  
store", it's a store that "renders" it's data in JSON.  (I hope it's  
clear that I think the world needs a "general JSON store" :)

>  There is nothing at all wrong with the above "schema" and it's  
> arguably the best way to store a document that you don't want to  
> conflict.  The couchdb document is always going to need metadata.   
> If it's not in _id then it's _farfagnugen and someone will  
> inevitably have the same issue.

Yep, exactly!  That's why I suggest formally separating the metadata  
out of the user data, and enhance the REST and view APIs so that you  
can get

a) just the user data (e.g. my AJAX app doesn't care or worry about  
the metadata)
b) both meta and user in the format like above
c) only meta for things where you don't care about the user data
d) maybe even a legacy mode where you inject meta into the userdata as  
it is today

geir

>
>
>
>
>> Now, I realize that no one ever said that CDB is a general JSON  
>> document store, rather it's a datastore that happens to return data  
>> in JSON.  The different is subtle, but very important.   It will be  
>> interesting to see how this space ("document databases") plays out,  
>> and if my concerns are valid.  Time will tell, I guess.
>>
>> BTW, for maximum utility,  I think that the view API will have to  
>> change as well.  There's incredible power in the CDB view model,  
>> but you'll want to be able to return a pure "user document" from a  
>> call to a view (conform to some specific "schema"), rather than at  
>> least what I understand is the current metadata-oriented structure.
>>
>> geir
>>
>>
>>
>>
>> On Jan 1, 2009, at 7:53 PM, Damien Katz wrote:
>>
>>> Why can't you just always stick the desired document into an body  
>>> field on the document? If you always do that, then you can round  
>>> trip without problem.
>>>
>>> -Damien
>>>
>>>
>>> On Jan 1, 2009, at 7:17 PM, Geir Magnusson Jr. wrote:
>>>
>>>>
>>>> On Jan 1, 2009, at 7:14 PM, Adam Kocoloski wrote:
>>>>
>>>>> On Jan 1, 2009, at 4:45 PM, Geir Magnusson Jr. wrote:
>>>>>
>>>>>> b) I should have the choice to not have it injected at all
>>>>>>
>>>>>> So why do I think this is a problem?  The 10gen appserver auto- 
>>>>>> injects an id field into the JSON documents that are stored in  
>>>>>> our database, Mongo.  Can you guess what the key is?  Yep - "_id"
>>>>>>
>>>>>> So how can I roundtrip a doc from 10gen through couch and  
>>>>>> back?  I can't.
>>>>>
>>>>> Perhaps its worth noting that CouchDB is perfectly comfortable  
>>>>> with externally generated _ids.  It only injects an _id if you  
>>>>> create a new document without one.  Best,
>>>>
>>>> I understand that.
>>>>
>>>> I was just pointing out a real-world case where a JSON doc from  
>>>> "somewhere else" runs into trouble...  (and yes, the issue  
>>>> applies equally to the 10gen platform, when coming from  
>>>> "somewhere else" :)
>>>>
>>>> geir
>>>>
>>>>>
>>>
>>
>


Mime
View raw message