Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.132.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=Xa59JFaAnjqYAvjFuqMutMT2bvAMVmOO5GwHRjQ0CWpKa9nUCwsEOQCvtPVV01pyF1
         hLUTis3izsdjvOKt3y49NFHsKKf6H2wHvclc27nGJF8AhjzCmbS1JKfUg8DeXiAl03S7
         TBOLx0w/SSlpj8EAoFuVBrj3BEUkc9zDqMS+0=
Message-ID: <e282921e0901121735m6e628a8xfbbf3f45a442479b@mail.gmail.com>
Date: Mon, 12 Jan 2009 17:35:48 -0800
From: "Chris Anderson" <jchris@gmail.com>
To: user@couchdb.apache.org
Subject: Re: Can I guarantee uniqueness in a field without using _id?
In-Reply-To: <20090113011256.GN11136@translab.its.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <518815b70901111530o23f6ce31yb40f974ea85467c0@mail.gmail.com>
	 <25893274-A543-4F9A-9FE3-A8E93938051B@apache.org>
	 <518815b70901121417ldf0d691l2838488fd5684697@mail.gmail.com>
	 <e2111bbb0901121424i7904c0bemb68ff930da4a07f4@mail.gmail.com>
	 <518815b70901121505l2fd3fc21uab28dcdaf419103c@mail.gmail.com>
	 <20090113011256.GN11136@translab.its.uci.edu>

On Mon, Jan 12, 2009 at 5:12 PM, James Marca
<jmarca@translab.its.uci.edu> wrote:
>  It always strikes me
> as a bit of a hack to overload the _id just to use its uniqueness
> features.  But given that one *can* get unique fields, I'd guess there
> are other things for the developers to solve first.


Supporting multiple unique keys would not lead us closer to the goal
of getting CouchDB to provide its current HTTP API, even when run
across a partitioned cluster of very many nodes.

The same story that applies about global state and uniqueness outside
of CouchDB also applies inside. The magic of hash functions allow us
to provide a single uniqueness constraint. If you need multiple
distinct unique keys, you'll need to track them as separate documents,
and deal with race conditions in your application. (There may be a
hack to get the _bulk_docs API to help you a little here, but it might
be that _bulk_docs transactions will have go away for the sake of
scalability.) Eventually consistent cluster transactions will be a
good challenge for client libraries.

I can understand the value you find in using multiple keys, but the
best way to get your application into Couch will be design it for
standalone documents. I'm glad it looks like you can get by without
multiple keys, there's a lot you can do with application-controlled
ids.

-- 
Chris Anderson
http://jchris.mfdz.com