incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: User Uniqueness Validation
Date Thu, 02 Jul 2009 08:21:24 GMT
On Tue, Jun 30, 2009 at 03:37:32PM -0700, Adam Wolff wrote:
> You can't check then act with couchdb -- there are no transactions. I think
> the only way to guarantee uniqueness is to try to put, using the natural
> primary key as the id the of the document. We are doing this by putting a
> document like this:{
>     _id : "",
>     userId : [reference_to_user_sha]
> }

Aside: even that won't work in a multi-master replicated setup (which is why
transactions were removed in the first place). Indeed: using the unique key
as the docid will make it more difficult for you in this scenario, because
instead of seeing two docs with the same E-mail address value, you will see
one doc with two conflicting revisions, which are more difficult to access.

Of course, the whole idea of having unique registered E-mail addresses
breaks down in a disconnected, multi-master environment. In principle you
need some kind of central 'registry' for checking whether the address has
already been taken or not. That central resource could be built from a
single instance of couchdb, but it would probably be better done using
something which implements transactions properly. And of course, if that
central resource goes down, users will no longer be able to register.

But in practice: I think it's OK to relax. When you're talking about a
single CouchDB instance, the race condition of two people trying to register
the same username within the same fraction of a second is very unlikely to
occur. If it does happen, you can detect it, and recover (e.g. E-mail the
loser and tell them that their registration failed, please try again; or
change the username to a different automatically-chosen one and E-mail this
to them)

When talking about E-mail addresses rather than local usernames, this is
even easier. If you are validating the E-mail addresses (by sending out a
confirmation link), you can be sure that the two 'conflicting' users are
actually the same person, so it's safe just to delete one.

So the approach I'm using is: use unique uuids for the docid - I am using
time-based ones, so views with equal keys are sorted by insertion date - and
then validate uniqueness of attributes before insertion or modification.



View raw message