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 kurt@arstechnica.com designates
 207.97.245.111 as permitted sender)
From: Kurt Mackey <kurt@arstechnica.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Mon, 12 Jan 2009 17:19:31 -0600
Subject: RE: Can I guarantee uniqueness in a field without using _id?
Thread-Topic: Can I guarantee uniqueness in a field without using _id?
Thread-Index: Acl1Ciyg3ZT55XbfQoq+Y5enX5PNMgAAPjrA
Message-ID: 
 <114A665E8FCADD4199D425621C5FF9C69D96F456@34093-MBX-C02.mex07a.mlsrvr.com>
References: <518815b70901111530o23f6ce31yb40f974ea85467c0@mail.gmail.com>
	 <25893274-A543-4F9A-9FE3-A8E93938051B@apache.org>
	 <518815b70901121417ldf0d691l2838488fd5684697@mail.gmail.com>
	 <e2111bbb0901121424i7904c0bemb68ff930da4a07f4@mail.gmail.com>
 <518815b70901121505l2fd3fc21uab28dcdaf419103c@mail.gmail.com>
In-Reply-To: <518815b70901121505l2fd3fc21uab28dcdaf419103c@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I don't know if there's ever been any discussion of redirects for a given d=
ocument ID, but that's one potential way Couch could handle something like =
this.

It might go something like this:

* Create a user, user gets a UUID as an identifier
* Create a redirect to user using key user-name-myusername
* Profit

You'd have to be clever about how you're creating users, maybe by generatin=
g a UUID first, then saving the unique redirect keys, then finally creating=
 the user document.

-Kurt


-----Original Message-----
From: Sunny Hirai [mailto:thesunny@gmail.com]=20
Sent: Monday, January 12, 2009 5:06 PM
To: user@couchdb.apache.org
Subject: Re: Can I guarantee uniqueness in a field without using _id?

>
> You have just identified the problem and solution that CouchDB solves
> with using a traditional RDBMS in a distributed environment. Check out
> the discussion on the CAP hypothesis (Others call it a theorem, I'm
> not convinced, but the basic idea is there).
>
> Or more succinctly, guaranteed uniqueness requires global state,
> global state does not scale.
>
> HTH,
> Paul Davis
>

Yeah, that's what I thought but I was hoping for something in between.

That is, all I want to do is guarantee uniqueness on one or a set of fields=
.
It seems to me that it would not require locks on reads and most of eventua=
l
consistency would be okay except for when dealing with an INSERT or an
UPDATE that changes the unique field. All other cases could work just like
before. It would only require a special locked lookup on the unique field o=
r
field set which could be optimized.

I know that CouchDB is not a solution to all problems (nor do I think it
should be) but it seems that this would be common for most web applications
which is a major CouchDB target. For example, almost any website needs
unique user_names. They also need unique names for pages in a wiki. Blogs
that use named pages would also have this problem.

In other words, this seems like an issue that happens so often in the web
computing world that I wonder if it should be supported in CouchDB.

Of course, the argument is to push that global state into the application
layer and store it elsewhere; however, the question is whether that
complexity would better service the developer if it was (a) in CouchDB or
(b) in the application itself.

Since it is a common case (as opposed to an edge case), perhaps there could
be some discussion of putting it into CouchDB.

Seriously though, would this not affect 100% of websites with a user base?
One solution, I suppose, is to store the user data in an SQL database, but =
I
prefer having as much as possible in CouchDB due to its flexible schemas.

Sunny