Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of ara.t.howard@gmail.com
 designates 66.249.82.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:content-type:content-transfer-encoding
         :mime-version:subject:date:x-mailer;
        b=ZeAHDWD95UVbmGMkP3JWDnyoIkgCE0oXthXG+W3gUdaZgDPMwY15EML91N9Xn6C6yS
         ctwzJ6e9/2jvmxvvLPtR0rcZcYLMev6qpZt7TKJN0fGv8W+fYUCJfJ89dc7T9cJtTKPc
         DNbwnPBjjyb3Q8AdxtKySOuCwTR11I6+irlyo=
Message-Id: <3CA3C700-106B-4577-9ABD-BDD4B422FE14@gmail.com>
From: ara howard <ara.t.howard@gmail.com>
To: couchdb-user@incubator.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: uuid, auto-increment, et al.
Date: Sun, 19 Oct 2008 22:47:23 -0600


i know counting objects, aka, distributed auto-increment in couch is  
consider bad form.  but let me propose a scenario a feel out peoples  
thoughts on a specific topic, in the interest in solving what i think  
*must* be solvable problem when using couch for an actual, real, live  
distributed system..

so let's say we want to store something

   login: foo
   password: bar

in a couchdb system, to authenticate users.  clearly, when given a  
login, we want to lookup a given login by said login and validate a  
password.

so consider this a bit - we could store docs using "account- 
#{ login }" or some other permutation of of the login name - the md5..  
whatever...

this obviously isn't great - two user signing up on two different  
nodes will cause a collision at replication time, but not at sign up  
time, meaning it'd be nearly impossible to actually create a system  
with multi-master nodes that would allow something as simple as user  
signup without crazy after the fact email resolution requiring a user  
to re-signup iff their login was a dup.

okay, take two, let couch generate the uuid, and replication proceeds  
as planned.  all is well.  that is, until you want to authenticate a  
user... doing a search based on

   emit( doc.login, doc )

returns 14 results.  two of them have the same password.  which user  
*is* this client logging in?

so this seems like a real wart: replication is *useless* without a  
better mechanism for generating uuids.  clearly we cannot expect a  
user to login via uuid, and clearly we cannot use the login, nor  
login:password combined as the uuid since that would create retro- 
active signup failures...

so, in a situation like this, requiring a unique set of data across  
all replicating systems, what would the 'couch way' be?

i think i'm stuck thinking inside a box and would love some insight to  
get out of it but, for now, i feel like the distributed and replicated  
nature of couch, while solving a host of issues, seems to open up  
vastly more complicated ones in the process.

kind regards.

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