incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Wall <jw...@google.com>
Subject Re: couchdb commit hooks
Date Mon, 09 Mar 2009 18:27:10 GMT
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 <awolff@gmail.com> 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 <damien@apache.org> 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
> >>
> >
> >
>

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