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