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 antony.blakey@gmail.com
 designates 209.85.198.229 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=XomzzDd1nMuTHdiJ7k/u/RD57Fwnq/XMdcDl+FUmDaKQ3TS+rZMfRig1NxM8CV14AL
         8eDMEvfbmYCgeqkLqhZjdqtQGuy80ZnDUV0jQOggwb9daXJ3y7Ls1Op+Ls+rW2iUpMSF
         MTSgVfMRjybywxG5dZNmJCweq8TMlAr0Cx4Eo=
Message-Id: <ACABD1CE-2E8E-491A-95C0-959820FBAA08@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: user@couchdb.apache.org
In-Reply-To: <48250456-2512-46BD-85E1-464457DBC995@pobox.com>
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 11:10:17 +1030
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>


On 31/12/2008, at 11:29 PM, Geir Magnusson Jr. wrote:

> What trouble?  I think this is *exactly* what should be done - have  
> CouchDB store documents that are :
>
> {
>    metadata : { _rev : X, _id : Y, _woogie: Z, .... anything that  
> needs to be added in the future, like other metadata like last  
> update date... },
>    userdata : {  .... the document you want to store .... }
> }
>
> and then offer APIs that let you :
>
> a) get to this document, for libraries and clients that know they  
> are talking to Couch and want to manipulate at this level
>
> b) return and accept the userdocument directly, for clients that  
> just want to consume or produce  JSON data, w/o caring about the  
> internal housekeeping

One of the issues complicating the logic of this discussion is that  
the document id is both metadata and, conceptually, a document member.  
That's why, although the purest model is to have the userdata as a  
member within a Couch document as you suggest, this doesn't look that  
appealing:

{
   metadata: {
     id: ...
     rev: ...
     ...
   }
   data: {
     ... the user's document ...
   }
}

Furthermore, from a scalability perspective, always having the  
metadata when you have the document, isn't a problem - the metadata is  
constrained. The reverse situation of always having the data when you  
have the metadata, is not constrained because the data is arbitrarily  
large. IMO this means that a solution such as this:

{
   id: ...
   rev: ...
   ...
   data: {
     ... the user's document ...
   }
}

isn't such a good idea compared to this:

{
   _metadata: {
     id: ...
     rev: ...
   }
   ... the user's document ...
}

Unfortunately the reserved token makes the structure non-reflexive  
without transformation, and although that's not currently an issue, I  
can imagine it complicating certain use-cases. It makes the system  
more complicated to reason about.

I'm struggling to objectively evaluate this model and your reflexive  
model - given Damien's attitude to this issue, my motivation to do so  
is somewhat depressed :/

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Did you hear about the Buddhist who refused Novocain during a root  
canal?
His goal: transcend dental medication.