Thanks for the reply damien! This led us directly to a solution. We had been thinking of the id as a function of the user, but it should be the other way around. On a side/related note, is there a spec for the couch-generated ids? How can I write an id that I know will never be generated automatically by couch? Thanks again, A
On Mon, Mar 9, 2009 at 11:00 AM, Damien Katz <[email protected]> wrote: > 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 >> > >
