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 <[EMAIL PROTECTED]>
wrote:
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
