couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: couchdb commit hooks
Date Mon, 09 Mar 2009 18:00:59 GMT
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


Mime
View raw message