incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davis" <>
Subject Re: Can I guarantee uniqueness in a field without using _id?
Date Tue, 13 Jan 2009 01:54:35 GMT

Also, I just realized that an easy way get close to what you want is
to use MD5's of all the stuff you want to be unique. Then your id's
remain reasonable unique etc.


On Mon, Jan 12, 2009 at 6:05 PM, Sunny Hirai <> wrote:
>> 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 eventual
> 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 or
> 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

View raw message