Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.198.234 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=Hj6GtO7PHuivA/qlUm/n22m+kQeLo2r08BW/BIkQWwJIBYTOcFlyq8vcSRsmR2rGBb
         xZAZiicF/EKuo+gcKRLiSj4jXRas1sKGZKx97C6MIYguT31DgIP4I8dNVd57SMRC34I6
         AFH9BYqmF2lS9Ord4fBBDjANPguMzGA1wsqxw=
Message-Id: <518EA584-E39C-4362-A73E-39D95784028D@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: user@couchdb.apache.org
In-Reply-To: <e282921e0812291551k75dc4e40vf0e83689f06f4f7b@mail.gmail.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: Tue, 30 Dec 2008 10:41:32 +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>
 <15C26192-DBC1-4256-85C4-E9C005BFE3E3@gmail.com>
 <e282921e0812291551k75dc4e40vf0e83689f06f4f7b@mail.gmail.com>


On 30/12/2008, at 10:21 AM, Chris Anderson wrote:

> On Mon, Dec 29, 2008 at 3:38 PM, Antony Blakey <antony.blakey@gmail.com 
> > wrote:
>
>> How is it 'easier to work with'? How does using _id and _rev  
>> everywhere make
>> it not easy? Surely it's not the difficulty of writing code?
>
> I argued in IM with Jan, that having _id and _rev only appear with
> prefixes in the context of a document, makes for a primitive type
> system. Any JSON object with _id and _rev fields is a CouchDB
> document. Where those same values appear elsewhere they are not
> prefixed, and it's not a document.
>
> I think it's nice that code which is designed to process documents
> will hit a speed bump if it is passed view rows. Duck typing is a
> fundamental advantage of JSON, and CouchDB's makes good use of it.
> It's nice to know by looking if you have a document on hand.

A similar argument could be applied to having _id and _rev everywhere,  
on the basis that it types the atom - wherever you see _id you know  
you have a document id, and similarly with _rev. And it makes it  
easier to write generic code that deals with ids and revs, because  
such code doesn't have to be aware of the context of either it's input  
or output.

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

Isn't it enough to see that a garden is beautiful without having to  
believe that there are fairies at the bottom of it too?
   -- Douglas Adams