incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Need help debugging mochiweb/Safari HTTP problems
Date Wed, 23 Jul 2008 21:36:47 GMT

On Jul 23, 2008, at 5:05 PM, Randall Leeds wrote:

> Maybe the answer is to allow both?
> If accessing from a language which can generate a sufficiently good  
> UUID,
> the application could generate it.
> Also add a mechanism to request a UUID from CouchDB in cases where  
> it's not
> possible to generate one.

Yes, asking CouchDB for the UUID is completely optional. Client can  
give docs any ID they want.

I'm also thinking we'll keep the current POST behavior too, since it's  
already there and works. We'll just document that it should not be  
used generally. Or maybe we should just rip it out. I can't decide  
just yet :)

-Damien

>
>
> On Wed, Jul 23, 2008 at 4:57 PM, Damien Katz <damien@apache.org>  
> wrote:
>
>>
>> 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
>>


Mime
View raw message