From user-return-7601-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Nov 13 16:52:27 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 42321 invoked from network); 13 Nov 2009 16:52:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Nov 2009 16:52:27 -0000 Received: (qmail 55511 invoked by uid 500); 13 Nov 2009 16:52:26 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 55441 invoked by uid 500); 13 Nov 2009 16:52:26 -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 55430 invoked by uid 99); 13 Nov 2009 16:52:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Nov 2009 16:52:26 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.217.214 as permitted sender) Received: from [209.85.217.214] (HELO mail-gx0-f214.google.com) (209.85.217.214) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Nov 2009 16:52:18 +0000 Received: by gxk6 with SMTP id 6so3243183gxk.13 for ; Fri, 13 Nov 2009 08:51:57 -0800 (PST) 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 :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=yBgoVcGW+e8AEEfMB6RDSQ+OPqc3lN8+lDDVBrNmhXI=; b=bwZeuUYD31+51CVVk++VucoK4XPj/gXLQaYmVS2KZZtYptLc/HQGJINM7uAfsokQup Or324mz2XuWrs8Cb78fF+vGeaUYZvcRlTHCvjpTRngJ+sKTe2pB+CL9ud0yCu1tHxBrl QcmoKTi5mKK/sxT6yNXI9kXsxOpVeUts306GA= 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=pi/FTA9D/QdOOsSqR84PJTJ4PFS3a6XkWqpCTFqTacdWzV65lQkt0t0YtvJ1t6tfE9 XH7ADQ/MGxNUjBmOv2HhB/fyyJ4StzdyOdIawp+38O9f3U6gbdC6qs6HaXLKLrT8Q6Md +claqjq3xMYbdxYKQj5NafYD2AU49J5DIRtgo= MIME-Version: 1.0 Received: by 10.100.59.5 with SMTP id h5mr5124526ana.83.1258131117467; Fri, 13 Nov 2009 08:51:57 -0800 (PST) In-Reply-To: <9b1d06140911111959g7f12f54fm853e14d15b6eb477@mail.gmail.com> References: <9b1d06140911111700k43d3f23eob40bf63fd1d43521@mail.gmail.com> <9b1d06140911111959g7f12f54fm853e14d15b6eb477@mail.gmail.com> From: Paul Davis Date: Fri, 13 Nov 2009 11:51:37 -0500 Message-ID: Subject: Re: Ensuring unique attributes across documents? To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Nov 11, 2009 at 10:59 PM, Cory Nelson wrote: > Indeed, that would be great if there were only one piece of data to > keep unique. =A0In fact, I'm already doing that for the user name. =A0But > what about the email? > > I guess this could really be made into a more generic question: how do > you create or alter one document only if pre-conditions are met in > other documents, in a way that doesn't risk permanent inconsistencies > if the database or client crash, or with partitioning? > > Or alternately: is this merely a design that worked in transactional > dbs but doesn't translate to something like CouchDB? =A0If so, what's > the recommended way to handle things like this? > > Thanks! Another thing to think about is what permanent inconsistencies means to you. For a user signup workflow, you could use autocomplete suggestions from a view to help the user pick a unique name and check if an entered user id exists. Then just submit the form and check a view if the new account is kosher. That's obviously racey, but generally it doesn't matter. How often are you going to have two people trying to signup with the same email address? And you can resolve race conditions by using the update seq. Who ever saved first wins. The loser just gets a friendly, "Oops, someone just registered that email address." Granted that doesn't prevent replication from ruining things, but how often do you want to replicate unknown data into the database holding user info? And another thought process is, do you really want globally unique email addresses? Or do you just want to prevent a spammer signing up thousands of accounts? Paul Davis