Unless you need sequential numbers, you could just generate the
desired IDs client side and save and let conflict detection handle if
it's non-unique. If you get a conflict error, then client must
generate another ID. Repeat until successful.
-Damien
On Mar 9, 2009, at 1:31 PM, Adam Wolff wrote:
Hi everyone,We're psyched about couchdb and are planning to use it
in our
production system. We have a nice model for documents in our system
that
builds directly off of the features of couchdb and makes a lot of
sense.
However, we're not sure how to use couchdb to handle users.
The problem boils down to the difficulty in handing out unique user
ids. We
understand that introduction of an AUTO INCREMENT behavior would add
global
shared state to the db, but right now it doesn't seem like you can
handle
this use case with the existing features of couchdb. (If I'm wrong
about
that PLEASE correct me!) We have implemented an act-then-check
procedure for
this for now, but the unpredictability of http request ordering
stills means
that there can be periods of inconsistent state.
I'm wishing for a function that could live in couch that could be
called to
generate an ID for a new document. This could return the date/time
or the
server node name or whatever. I'm sure I haven't thought through the
potential difficulties here, but I'm curious about the thinking on
this, or
whether these features are planned, or whatever.
In the long term, if the couch features don't change, I think we'll
have to
use a SQL store for users and couch for documents, but that would
dramatically increase the complexity of the system.
Thanks in advance,
A
