couchdb commit hooks

[Adam Wolff <aw...@gmail.com>]

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

Re: couchdb commit hooks

[Adam Wolff <aw...@gmail.com>]

No, we specifically want a user id that can claim multiple email addresses,
but doesn't have to be chosen by the user. Damien's post made me realize
that we can POST a record for the user and get the generated id, and then
create separate documents for each of the user's email addresses where the
document id is the email address, and the document contains the generated
id.
A


On Mon, Mar 9, 2009 at 12:25 PM, Noah Slater <ns...@apache.org> wrote:

> >> 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.
>
> Sounds to me like your problems are stemming from your use of a surrogate
> primary key for users. Using a surrogate key is something of a left-over
> from
> decades of bad relational database design. I would suggest that you take a
> closer look to see if you cant find a true primary key, like
> username/email.
>
> --
> Noah Slater, http://tumbolia.org/nslater
>

Re: couchdb commit hooks

[Noah Slater <ns...@apache.org>]

>> 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.

Sounds to me like your problems are stemming from your use of a surrogate
primary key for users. Using a surrogate key is something of a left-over from
decades of bad relational database design. I would suggest that you take a
closer look to see if you cant find a true primary key, like username/email.

-- 
Noah Slater, http://tumbolia.org/nslater

Re: couchdb commit hooks

[Noah Slater <ns...@apache.org>]

On Mon, Mar 09, 2009 at 01:27:10PM -0500, Jeremy Wall wrote:
> I believe the couch ids are UUID type 4 ids. You shouldn't need to worry too
> much about colliding with them.

Too much? Heh.

I'll give you 10 Internets collide before the heat death of the universe.

-- 
Noah Slater, http://tumbolia.org/nslater

Re: couchdb commit hooks

[Jeremy Wall <jw...@google.com>]

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 <aw...@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 <da...@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
> >>
> >
> >
>

Re: couchdb commit hooks

[Adam Wolff <aw...@gmail.com>]

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 <da...@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
>>
>
>

Re: couchdb commit hooks

[Damien Katz <da...@apache.org>]

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