From user-return-7581-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Nov 12 22:44:34 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 30857 invoked from network); 12 Nov 2009 22:44:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Nov 2009 22:44:34 -0000 Received: (qmail 68013 invoked by uid 500); 12 Nov 2009 22:44:33 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 67942 invoked by uid 500); 12 Nov 2009 22:44:32 -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 67931 invoked by uid 99); 12 Nov 2009 22:44:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Nov 2009 22:44:32 +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 zachary.zolton@gmail.com designates 209.85.218.218 as permitted sender) Received: from [209.85.218.218] (HELO mail-bw0-f218.google.com) (209.85.218.218) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Nov 2009 22:44:22 +0000 Received: by bwz10 with SMTP id 10so2907789bwz.35 for ; Thu, 12 Nov 2009 14:44:02 -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=7ztOYFQt7DvSJfBDSuaBzxKPYwK2/Ere84gqn/JcFjw=; b=JA7xYh3LDaEzo3+FfuIRW/PoSxk81qrVdSpIQjUQkXe/G7+oUwGugo4fEeBt+NW/jn qbZyKVXoMKcz0eFg1ZLJEjV8s9bONn90EXEasb3nH+1OX8J6ofiY/lD9PakwJhQuZT6A dXwz5y5zDEPGkVxywceL4qnoE9J5zLAb7iksA= 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=vFku2go8VKbFDrO/S3eIQ1Fwl9zqxLOC42JFLYKeY6gMlL2ExCQ58eEGog+avD7kvn 5yJoo6uk5zQvPbEF7iPfr0OwxwlZ3D4daq2cWSLKmfaVp9gzEpK4FgYXqBL0FEtG9O+n brhhK8ybWICLWHi1dBwTxnRVP5Y0j63aEVl5s= MIME-Version: 1.0 Received: by 10.204.154.216 with SMTP id p24mr4021339bkw.16.1258065842243; Thu, 12 Nov 2009 14:44:02 -0800 (PST) In-Reply-To: References: <9b1d06140911111700k43d3f23eob40bf63fd1d43521@mail.gmail.com> <9b1d06140911111959g7f12f54fm853e14d15b6eb477@mail.gmail.com> From: Zachary Zolton Date: Thu, 12 Nov 2009 16:43:41 -0600 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 Sure, you could even maintain a database just for uniqueness, with strings like "attr_name-attr_value" as the doc IDs. BUT, you still have problems: * Writing multiple docs leaves an open window for race conditions (not so bad really) * Any other server you replicate from may have already accepted a doc with that ID You can avoid this by only writing to a single master database, but you should be aware that you're introducing a Single Point of Failure. At that point you could even consider using a transactional RDBMS to allocate the unique values. --Zach On Thu, Nov 12, 2009 at 3:46 PM, Adam Wolff wrote: > Put a separate document under the email address that refers to the userna= me. > Use view collation to build the user record. > > A > > On Wed, Nov 11, 2009 at 7: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. =A0Bu= t >> 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! >> >> On Wed, Nov 11, 2009 at 6:14 PM, Zachary Zolton >> wrote: >> > You COULD use the User document's ID to ensure uniqueness. The second >> > PUT to the same database URL would result in an HTTP 409 status code. >> > >> > Here it is on StackOverflow: >> > >> http://stackoverflow.com/questions/1058258/does-couchdb-support-unqiue-k= ey-constraint >> > >> > >> > On Wed, Nov 11, 2009 at 7:00 PM, Cory Nelson wrote= : >> >> Hello, >> >> >> >> I'm trying to implement a typical user signup operation: when you >> >> finally add a user to the database, you want it to have both a unique >> >> user name, and a unique email. =A0In SQL I'd do something like: >> >> >> >> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE >> >> >> >> count =3D SELECT COUNT(*) FROM t_users WHERE name=3D? OR email=3D? >> >> >> >> if(count =3D=3D 0) >> >> { >> >> INSERT INTO t_users VALUES(...) >> >> COMMIT >> >> } >> >> else >> >> { >> >> ROLLBACK >> >> } >> >> >> >> Can anyone give an example of how to achieve the same thing in CouchD= B? >> >> >> >> -- >> >> Cory Nelson >> >> >> > >> >