No, we specifically want a user id that can claim multiple email addresses, but doesn't have to be chosen by the user. Damien's post made me realize that we can POST a record for the user and get the generated id, and then create separate documents for each of the user's email addresses where the document id is the email address, and the document contains the generated id. A
On Mon, Mar 9, 2009 at 12:25 PM, Noah Slater <[email protected]> wrote: > >> 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. > > Sounds to me like your problems are stemming from your use of a surrogate > primary key for users. Using a surrogate key is something of a left-over > from > decades of bad relational database design. I would suggest that you take a > closer look to see if you cant find a true primary key, like > username/email. > > -- > Noah Slater, http://tumbolia.org/nslater >
