Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 4943 invoked from network); 14 Jan 2009 01:40:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Jan 2009 01:40:01 -0000 Received: (qmail 34192 invoked by uid 500); 14 Jan 2009 01:39:55 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 34153 invoked by uid 500); 14 Jan 2009 01:39:55 -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 34142 invoked by uid 99); 14 Jan 2009 01:39:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Jan 2009 17:39:54 -0800 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 antony.blakey@gmail.com designates 209.85.221.21 as permitted sender) Received: from [209.85.221.21] (HELO mail-qy0-f21.google.com) (209.85.221.21) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Jan 2009 01:39:44 +0000 Received: by qyk14 with SMTP id 14so377872qyk.11 for ; Tue, 13 Jan 2009 17:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=v/VRQqKHSgn9XOdI7G6minClQYfKQoIA/4TeADPWKK0=; b=CzVP6mdkJjnkj0Z7HKriyokYs2IybH7Raxue4C9P86+ntEbjRKvB+Z8ig1wXyYKuU6 sgTg82aRqLVh3ogXc5I73WbsYG7gOHVoPlMTejFtEa0qQbfwMjuKIxgdYjsa4OHSo1BG ahbbtxZvaNDI7TdDANaBIJngJdc8rkMmTkjpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=hzfDzjaDSwRUlNOJ2GRN8VnfASViTx9b2ie+Te47WyIOYAEBFJd2T1O+iflh61J8g8 eBTyaHu9lQeUU9l2dbNQcRpkoivG8nyykP7iwsxHiE+bY85zYypV1QINEynBuWuKPcp4 7xQXXldG7mqG1du/smnCU4wtNkbO4DHTGodyo= Received: by 10.214.46.20 with SMTP id t20mr27797380qat.103.1231897163754; Tue, 13 Jan 2009 17:39:23 -0800 (PST) Received: from ?192.168.0.19? (ppp121-45-81-35.lns10.adl6.internode.on.net [121.45.81.35]) by mx.google.com with ESMTPS id 5sm19110456ywd.22.2009.01.13.17.39.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Jan 2009 17:39:23 -0800 (PST) Message-Id: <482703BB-BBA1-4565-BF8A-2CAFCA190001@gmail.com> From: Antony Blakey To: user@couchdb.apache.org In-Reply-To: <791F7A73-DB3B-4822-8D93-A904802A427A@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Can I guarantee uniqueness in a field without using _id? Date: Wed, 14 Jan 2009 12:09:18 +1030 References: <518815b70901111530o23f6ce31yb40f974ea85467c0@mail.gmail.com> <791F7A73-DB3B-4822-8D93-A904802A427A@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On 14/01/2009, at 11:40 AM, ara.t.howard wrote: > assume your system will be distributed at some point and that global > uniqueness is hard whether in a rdbms or docms. even auto-increment > will fail here. now take the middle path - only writes need to be > unique because, if all of them are, objects can distribute between > nodes freely (since we already know they are unique inside the > system). > > so just make a rule - you will require a single couchdb instance to > be available to check uniqueness, but any couchdb instance up to > perform reads or writes which do not need to be unique (like > comments with a timestamp or something). > > so host a couchdb at something like > > http://domain.org/unique > > use this to check the uniqueness of fields. for instance, so see if > a name is in the system try to put > > { '_id' : 'name::yourname' } > > or something you app will use to decide the uniqueness of a name in > the system. think of it as a global hash you can check for a given > key. > > to me this seems quite reasonable, it's a nod to the fact that > distributed uniqueness is very hard, while at the same time > accepting that most applications are difficult to build without it. > the constraint on your system will simply be that the uniqueness > server must be up for some operations to succeed, but if you design > for it many will be able to perform many other operations in the > face of a uniqueness server failure. I am doing a similar thing - many read-replicas and one write replica. My domain tolerates unavailability of write-access, but not read- access. The application is distributed with each couch instance, and as soon as a user logs on with write access, they are switched to a unique write server. I switch the user on logon to the write server, for all access, because otherwise they don't get any locally consistent view. Hence I don't distinguish between data-needing-uniqueness or not. For each domain object, I determine the name used to identify it within it's parent context e.g. a user is an email address, a page in a CMS is a parent id + name. I then use that identity, either with a prefix (e.g. user:antony.blakey@...) or in a separate db, as the document id. As soon as I use a prefix on any data in a given db, I use a prefix on all data in that db that uses domain keys on ids. As an aside, for hierarchic data (which covers any heterogenous data with a qualified name/uniqueness constraint), if you have a single write point then you can assign a UUID to each node when it is created, and presuming that field is immutable, you can then qualify the child node using the parent's UUID rather than the parent's id (which can grow in a nasty fashion). Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The greatest challenge to any thinker is stating the problem in a way that will allow a solution -- Bertrand Russell