Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <A6E7814D-C4FD-4720-A6D4-9104E514C667@apache.org>
From: Damien Katz <damien@apache.org>
To: couchdb-dev@incubator.apache.org
In-Reply-To: <ec7a93a0807231224s1967c4aaxa4bb34c5139efabc@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 v926)
Subject: Re: Need help debugging mochiweb/Safari HTTP problems
Date: Wed, 23 Jul 2008 16:57:38 -0400
References: <FC224F1A-9757-4633-A0AC-6D4598A0FBCF@apache.org>
 <ec7a93a0807231224s1967c4aaxa4bb34c5139efabc@mail.gmail.com>


On Jul 23, 2008, at 3:24 PM, Randall Leeds wrote:

> On Wed, Jul 23, 2008 at 3:01 PM, Damien Katz <damien@apache.org>  
> wrote:
>
>> document creation. The problem is the generated id for the document  
>> is a
>> UUID generated server side, so the server has no way to distinguish  
>> if a
>> request is a new request or a resend of an already processed  
>> request, and so
>> generates another UUID and thus creates another new document. But  
>> if the
>> UUID is generated by the client, then the resend will cause a  
>> conflict
>> error, that UUID already exists in the DB, thus eliminating the  
>> duplicate
>> data.
>>
>
> It seems to me the easiest solution is that the client should  
> probably be
> responsible for generating UUIDs.
> Is there a counter-argument that indicates CouchDB being responsible  
> for
> this? The only one I come up with quickly is that it puts an extra  
> burden on
> the client. Not such a huge burden though. As far as the server  
> goes, client
> generation seems to adhere to the wonderful tenet K.I.S.S.
>

The only problem with this approach is there is no standard way of  
generating a UUID in a browser. CouchDB uses a crypto level RNG to  
create the UUIDs, which is pretty much mandatory to minimize spurious  
conflicts. But generating true UUIDs isn't possible in most browsers  
(the entropy of the browser PRNG generator is usually significantly  
below the 128 bits possible for a UUID).

One idea is CouchDB can generate the UUID still in a separate step. So  
the client first asks the server to generate a UUID, then the client  
uses that UUID to save the document. It's inefficient in that it would  
require two transactions, but it can make this more efficient if the  
client library (e.g couch.js) pre-requests UUIDs in bulk, and then  
keeps the un-used ones around in memory until more are needed.

-Damien