incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Wolff <>
Subject Re: couchdb commit hooks
Date Mon, 09 Mar 2009 18:24:00 GMT
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
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,

On Mon, Mar 9, 2009 at 11:00 AM, Damien Katz <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message