Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <a01fc5d10810201431s657c2291v58fff348e19df684@mail.gmail.com>
Date: Mon, 20 Oct 2008 22:31:30 +0100
From: "Nick Johnson" <arachnid@notdot.net>
To: couchdb-user@incubator.apache.org
Subject: Re: uuid, auto-increment, et al.
Cc: "Antony Blakey" <antony.blakey@gmail.com>
In-Reply-To: <28C5C039-4B15-4160-A4EF-6E834BA439E4@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_92077_20454610.1224538290380"
References: <3CA3C700-106B-4577-9ABD-BDD4B422FE14@gmail.com>
	 <CB678ECE-7737-4CA5-B866-D9D1A44C521A@gmail.com>
	 <28C5C039-4B15-4160-A4EF-6E834BA439E4@gmail.com>

------=_Part_92077_20454610.1224538290380
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Oct 20, 2008 at 5:10 PM, ara.t.howard <ara.t.howard@gmail.com>wrote:

>
> On Oct 19, 2008, at 11:34 PM, Antony Blakey wrote:
>
>  3. Use couchdb in a single-writer multiple-reader scenario. If you only do
>> that for those activities that require uniqueness then you have consistency
>> issues to deal with because replication is asynchronous. One way to do that
>> is to switch a session to the writable server as soon as you need
>> uniqueness. The single writer becomes a bottleneck, but this is what I'm
>> doing because it matches my information architecture.
>>
>> 4. Use a central specialized server to check uniqueness and generate an
>> opaque userid token that you would subsequently use as a key (you shouldn't
>> use the username as a key). An ldap server or something like it. Equivalent
>> to the option above, but the single server only needs to deal with the
>> particular operations requiring uniqueness. It's still a single point of
>> failure, but I don't think you can get around that if you want synchronous
>> global uniqueness testing.
>>
>
>
>
> you know, thinking about this further is causing me to wonder if even
> that'd do it.  consider a single write master an attempting to check if a
> given login is unique, with couch there no way to ensure that two keys are
> unique other than using said key as the _id for the doc.  it's possible
> that'd work in some cases, but consider
>
>  user
>    login : string (unique)
>    password : string
>    email: string (unique)
>
> and it suddenly becomes difficult again - we cannot ensure both are unique
> with an atomic test/set.


If you have 'user' docs and 'email' docs (which may simply contain nothing
but a reference to the user that owns the email), you can attempt to insert
both a new user doc and a new email doc in a single bulk write transaction.
The transaction will fail if either one already exists.

This doesn't really work with my proposed sharding method, however, since
you can't guarantee both entities will hash to the same shard. You could
insert one doc then the other, and if the second insert fails, roll back the
first one, though.


> we cannot simply combine them as a key because
>
>  login: foo
>  email: foo@barcom
>
> and
>
>  login: bar
>  emai: foo@bar.com
>
> would become a unique pair.  rather we'd have to do something like keep a
> master index of all docs - or perhaps just a blank doc (index) mapping
> emails to users and bulk update the pair of them together.
>
> so there are probably solutions lurking, but all of them seem very
> complicated to allow something as simple as allowing a user to have a simple
> piece of memorable information to enter and have an application respond by
> mapping that directly to the user's data.
>
> obviously we can solve the issue with multiple writes and reads combined,
> but that's not particularly good if other applications might be using this
> data actively (which is of course the case with a single writer).
>
> to summarize the problem - what's the preferred method of ensuring that a
> field of a couchdb doc is unique across all docs if that key cannot be the
> _id itself?  is the only method to write it, process a view to find all docs
> which might have a duplicate field, and then possibly to delete the
> original?  it's all i imagine now but that's pretty tricky in a high
> concurrency situation because of the mutually destructive race condition
> what proceeds:
>
>  a - write doc with foo=bar
>  b - write doc with foo=bar
>
>  a - read list of all docs where foo==bar
>  b - read list of all docs where foo==bar
>
>  a - decide ours was a dup.  destroy it.  report error to user
>  b - decode ours was a dup.  destroy it. report error to user.
>
> which is full of messiness if the network or db goes down but, most
> importantly, can fail even when it's up.
>
> what am i missing when it comes to attempting to model a doc field which
> should contain a unique value?
>
> cheers.
>
>
> a @ http://codeforpeople.com/
> --
> we can deny everything, except that we have the possibility of being
> better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
>

------=_Part_92077_20454610.1224538290380--