couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds" <>
Subject Re: Need help debugging mochiweb/Safari HTTP problems
Date Wed, 23 Jul 2008 21:05:27 GMT
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.

On Wed, Jul 23, 2008 at 4:57 PM, Damien Katz <> wrote:

> On Jul 23, 2008, at 3:24 PM, Randall Leeds wrote:
>  On Wed, Jul 23, 2008 at 3:01 PM, Damien Katz <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message