Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of awolff@gmail.com designates
 209.85.198.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=EKpi7SpKM0IEpdpZO76nQAclutdixIGkIV+Gyu/heKqIVimfKxM/X4oILsu2gimBYH
         XQjO9TgG0eyZGGi6lsVSfaIhpUhsXA/ObrbZtpG35Ny/3qlwqyBRQ0VMesNsq6T05w9i
         UDYcjUPv6YM5dCcOEK8kopw11wv+WacmxkHik=
MIME-Version: 1.0
In-Reply-To: <6776036A-BA46-42BB-B5A1-E89528EA80E2@apache.org>
References: <e8d26ac40903091031p5f8fe1a9pe35f150064137fe2@mail.gmail.com>
	 <6776036A-BA46-42BB-B5A1-E89528EA80E2@apache.org>
Date: Mon, 9 Mar 2009 11:24:00 -0700
Message-ID: <e8d26ac40903091124q18bc6549r35ede1b8228fce8@mail.gmail.com>
Subject: Re: couchdb commit hooks
From: Adam Wolff <awolff@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=0016364c5db90fa2d70464b3bd3b

--0016364c5db90fa2d70464b3bd3b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

--0016364c5db90fa2d70464b3bd3b--