Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 59876 invoked from network); 30 Jun 2009 22:37:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Jun 2009 22:37:54 -0000 Received: (qmail 59098 invoked by uid 500); 30 Jun 2009 22:38:03 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 59016 invoked by uid 500); 30 Jun 2009 22:38:03 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 59006 invoked by uid 99); 30 Jun 2009 22:38:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jun 2009 22:38:03 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of awolff@gmail.com designates 209.85.221.177 as permitted sender) Received: from [209.85.221.177] (HELO mail-qy0-f177.google.com) (209.85.221.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jun 2009 22:37:53 +0000 Received: by qyk7 with SMTP id 7so637031qyk.13 for ; Tue, 30 Jun 2009 15:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=XkrmlO879de9d4qc75hM5XmVCtTf7E7EH0LBoPg/pKw=; b=Eu9WdoA497Ut1uTLQi2eb89gCi2tnYV2hNwsu5aNJ425U+5xEO3x5zLm1Th0n6PiRY auAF1GteI+AFGXklfBZPRKBfFXnQyRs1fjW37QK9uDf24kiTCm7yphwapmiYLaF1zscb +seyTpkb6PorNz/vbo5fDuSd4Y6+mnz2LGm7I= 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=imrxA/MKa55/2jBZYo5aAoOm+16d2z48HkW71lrwcPY1Ke5CkdCv/LnjPSewYeZS+w jaI4QWgQ7z3NdOYbjykT6JG/Nbh2NNGl0C/XgSYxuI66WPwoKddM0QoGD+roQBKr9RWU gWAJQVbWyxkCtxi6QL2ROXAnMEreuncB3uiTg= MIME-Version: 1.0 Received: by 10.229.99.210 with SMTP id v18mr2514002qcn.76.1246401452630; Tue, 30 Jun 2009 15:37:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jun 2009 15:37:32 -0700 Message-ID: Subject: Re: User Uniqueness Validation From: Adam Wolff To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016367f9a00d4e381046d98737d X-Virus-Checked: Checked by ClamAV on apache.org --0016367f9a00d4e381046d98737d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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:{ _id : "awolff@gmail.com", userId : [reference_to_user_sha] } This way, you can tell if the email address is claimed and take it all in one shot. Then it's trivial to create views which accumulate the user data 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 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 use = a > generated id for users. This makes life much easier in the software's lif= e > cycle. For example, what if you want to do away with user names and just = use > e-mail addresses? Or you need to generically identify a user but don't ha= ve > 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 t= he > e-mail is already registered. This also scales nicely with cases where us= ers > can have more than one email associated to them. > > -- > Sam Bisbee > > > > --0016367f9a00d4e381046d98737d--