incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ara.t.howard" <>
Subject Re: uuid, auto-increment, et al.
Date Mon, 20 Oct 2008 07:18:03 GMT

On Oct 19, 2008, at 11:34 PM, Antony Blakey wrote:

> If you want to ensure that the username is unique at the time the  
> user enters it, then you need a central synchronous service. Using  
> the username/password as a pair isn't a good idea because it only  
> takes two naive/lazy users to use a similar password (based say on  
> their username? :) for collision to subsequently occur.
> I've been considering this in a production environment, and I saw  
> four solutions:
> 1. Append some form of unique id from the server you are currently  
> talking to i.e. checksum then machine uuid + process. Any checksum  
> is going to have some chance of global collision, but it could be  
> made vanishingly small. Not great for the user because they have a  
> complicated username.
> 2. Define your user interaction such that it can deal with  
> subsequently needing to add some suffix to the username e.g. when  
> you get a replication conflict (which could involve an number of  
> conflicts equal to the number of writable replicas), you amend some/ 
> all of the names to include a serial number and then email the user.  
> This complicates things for the user, and they end up with a  
> username they haven't chosen, or they may not see the email and end  
> up abusing tech support etc etc.
> 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.

a validating and complete treatment - thanks.

so pretty much my thoughts exactly.  the further advantage that #3 has  
is that is means *nothing* has to be done up front, it's only when the  
app scales out the multiple dbs that work needs to be done but, at  
that time, it's presumably justified.  i've also considered #4 heavily  
(a possible great web service actually...) probably will go will some  
sort of hybrid.  that is to say always get them from the single db,  
but in a way that could require zero code changes when getting an id  
meant hitting some central service


for instance.  that way i can run with single writer, and seamlessly  
move to #4 later.  i don't even think that would need to be a single  
point of failure as having a couple of those machines would be trivial  
if the knew about each other and generated ideas with small amount of  
server based uniqueness in them, for instance


all coming from behind a triple set of id generators.  in the end it  
does seem like only #3 and 4 are appropriate for systems used by people.


a @
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama

View raw message