I don't know if there's ever been any discussion of redirects for a given document 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 generating a UUID first, then saving the unique redirect keys, then finally creating the user document. -Kurt -----Original Message----- From: Sunny Hirai [mailto:[email protected]] Sent: Monday, January 12, 2009 5:06 PM To: [email protected] 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 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
