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 zachary.zolton@gmail.com
 designates 209.85.218.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=FthqOxNCy45sATzMf/oPLahtLYNPjlQbbCykXNtKOrB+QeTCt9oUF8MZtWuljE+ihZ
         P1r1/lbM4svZbTGvfFbydE+MV9wH8Q882UGxJIK514HlbaLR1wvgX2rhb6qP9tV6vcbZ
         AAPqy8xMFc/TG+rAaQ2eKFwNo0yjQEl8SP/VE=
MIME-Version: 1.0
In-Reply-To: <DE36B623-E452-4ED1-BC0A-3DC198480124@jasondavies.com>
References: <W9905626105289731246399116@webmail32>
 <e8d26ac40906301537l4f749d94rbc2c3677b519e593@mail.gmail.com>
	<DE36B623-E452-4ED1-BC0A-3DC198480124@jasondavies.com>
From: Zachary Zolton <zachary.zolton@gmail.com>
Date: Tue, 30 Jun 2009 21:50:23 -0500
Message-ID: <f728979f0906301950p6bc09fean60975c189f7f8e1b@mail.gmail.com>
Subject: Re: User Uniqueness Validation
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Okay, so if I'm reading this correctly, the procedure should go like this:

get next uuid
put doc user_email:foo@bar.com (with reference to uuid)
if 409
    display email address is already taken
else
    put doc user_name:foobar (with reference to uuid)
    if 409
        delete user_email:foo@bar.com
        display user name is already taken
    else
        create user doc (with email_address and user_name)
        display success message

Thanks for your input!

=97Zach


On Tue, Jun 30, 2009 at 6:22 PM, Jason Davies<jason@jasondavies.com> wrote:
> An extension to this scheme would be to add some kind of prefix to the ID=
,
> in case you want to have more than one "uniqueness constraint". =A0So you
> might have "user_email:foo@bar.com" and "newsletter_email:foo@bar.com" fo=
r
> example to avoid the two constraints interfering with each other.
> --
> Jason Davies
>
> www.jasondavies.com
>
> On 30 Jun 2009, at 23:37, Adam Wolff wrote:
>
>> You can't check then act with couchdb -- there are no transactions. I
>> think
>> the only way to guarantee uniqueness is to try to put, using the natural
>> primary key as the id the of the document. We are doing this by putting =
a
>> document like this:{
>> =A0 _id : "awolff@gmail.com",
>> =A0 userId : [reference_to_user_sha]
>> }
>>
>> This way, you can tell if the email address is claimed and take it all i=
n
>> one shot. Then it's trivial to create views which accumulate the user da=
ta
>> as well.
>>
>> HTH - it took us a while to figure this one out.
>> A
>>
>> On Tue, Jun 30, 2009 at 2:58 PM, Sam Bisbee <sbisbee@computervip.com>
>> wrote:
>>
>>> Greetings,
>>>
>>>> So, I've got a situation where I want to maintain a CouchDB database
>>>> of users that have a user name and email address. Given that the user
>>>> name needs to be unique=97and is significant to my URL scheme=97I've
>>>> chosen to use that as the document ID.
>>>
>>> While I don't know the full context of your situation, I would still us=
e
>>> a
>>> generated id for users. This makes life much easier in the software's
>>> life
>>> cycle. For example, what if you want to do away with user names and jus=
t
>>> use
>>> e-mail addresses? Or you need to generically identify a user but don't
>>> have
>>> access to their user name? Now you need to re-rig your code to use a
>>> different id scheme. I've found it much easier to just take the user id
>>> generated by the index or my code's logic and use that as my primary
>>> identifier in the database. I've found this to be database agnostic.
>>>
>>>> However, I'd also like to maintain uniqueness of the email addresses
>>>> across users... Any ideas about how to best accomplish this?
>>>
>>> While those with more experience than me on the Couch may have a better
>>> technique, I have always just constructed a view that outputs the users=
'
>>> email addresses as keys. Then I can query the view with
>>> ?key=3D'emailInQuestion' and if the returned array has any results then=
 the
>>> e-mail is already registered. This also scales nicely with cases where
>>> users
>>> can have more than one email associated to them.
>>>
>>> --
>>> Sam Bisbee
>>>
>>>
>>>
>>>
>
>