Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Message-Id: <7B58C5C8-388D-4CFC-B2B1-A473591E4CA2@pobox.com>
From: "Geir Magnusson Jr." <geir@pobox.com>
To: user@couchdb.apache.org
In-Reply-To: <34022C74-BE1B-40DB-940A-57632AE6A98A@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Changing rev to _rev in view results (Was: Re: newbie question
 #1)
Date: Thu, 1 Jan 2009 20:24:29 -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>

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 :

  {
     _rev : ...
     _id : ...
     mydata : { ... the real document ... }
  }

then I think that CDB loses something in terms of being a general JSON  
document store.

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