I believe the couch ids are UUID type 4 ids. You shouldn't need to worry too much about colliding with them.
On Mon, Mar 9, 2009 at 1:24 PM, Adam Wolff <[email protected]> wrote: > 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 > >> > > > > >
