Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of theflinnster@gmail.com
 designates 74.125.44.30 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=Oj2YKZF6rGUrWIxMybICYJ4vN3q9SyoAuftDFGT5a2TweL6qEDUwWIUGOWrrP4LWZo
         PFmVs2MAgM4GQ1axOa6w4mq7jzQVlnvXzyA7Co34fIItQ4LMPFyMTEtRLHG6opwM79IY
         pvyxrGYtmTjidSaqe6w06l3D6ghtYYilS1Aac=
Message-Id: <EAA706C5-77DF-4F28-AD4F-0130E338892C@gmail.com>
From: Flinn Mueller <theflinnster@gmail.com>
To: user@couchdb.apache.org
In-Reply-To: <7B58C5C8-388D-4CFC-B2B1-A473591E4CA2@pobox.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Changing rev to _rev in view results (Was: Re: newbie question
 #1)
Date: Thu, 1 Jan 2009 21:14:07 -0500
References: <98979283-BB61-4D15-AF05-196979FA42BC@pobox.com>
 <e2111bbb0812280526q2766d197ld38f250d25d8e890@mail.gmail.com>
 <49C5583B-254D-4D4D-A4F7-AD7306E758F1@gmail.com>
 <A67E2901-CD92-4C24-B4E3-7955F2477766@apache.org>
 <8A2A146E-F011-4502-9DD9-336300392CDC@apache.org>
 <0743DF91-9015-43DD-9A0F-7E79D6DF4632@gmail.com>
 <E8D0BEEA-7E36-4C7E-A052-B3D724500A65@pobox.com>
 <0DE02009-32CB-4A88-8C39-7942E00BF8D6@apache.org>
 <2CC999E5-9D81-4981-B544-1977B9D16405@gmail.com>
 <154D8F25-87B3-49DC-9D80-6C68C946ECAF@gmail.com>
 <34FCDB16-6D06-4401-BCD8-0B053E2E935E@gmail.com>
 <48250456-2512-46BD-85E1-464457DBC995@pobox.com>
 <ACABD1CE-2E8E-491A-95C0-959820FBAA08@gmail.com>
 <AC6694DA-BA29-4D7E-A90E-31ABD10E1A9F@pobox.com>
 <48F376DC-9521-4A0C-9652-C4AB24769E7F@gmail.com>
 <3164E1E8-098C-4511-B147-F31241FC7724@pobox.com>
 <34022C74-BE1B-40DB-940A-57632AE6A98A@apache.org>
 <7B58C5C8-388D-4CFC-B2B1-A473591E4CA2@pobox.com>

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?


> {
>    _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.  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.


> 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
>>>
>>>>
>>
>