On 12 Nov 2009, at 23:43, Zachary Zolton wrote: > Sure, you could even maintain a database just for uniqueness, with > strings like "attr_name-attr_value" as the doc IDs. > > BUT, you still have problems: > * Writing multiple docs leaves an open window for race conditions > (not so bad really) > * Any other server you replicate from may have already accepted a > doc with that ID > > You can avoid this by only writing to a single master database, but > you should be aware that you're introducing a Single Point of Failure. > At that point you could even consider using a transactional RDBMS to > allocate the unique values.
or a lightweight redis store. If I'd go for the SPOF route, I'd build the most lightweight solution possible. Cheers Jan -- > > --Zach > > On Thu, Nov 12, 2009 at 3:46 PM, Adam Wolff <awo...@gmail.com> wrote: >> Put a separate document under the email address that refers to the username. >> Use view collation to build the user record. >> >> A >> >> On Wed, Nov 11, 2009 at 7:59 PM, Cory Nelson <phro...@gmail.com> wrote: >> >>> Indeed, that would be great if there were only one piece of data to >>> keep unique. In fact, I'm already doing that for the user name. But >>> what about the email? >>> >>> I guess this could really be made into a more generic question: how do >>> you create or alter one document only if pre-conditions are met in >>> other documents, in a way that doesn't risk permanent inconsistencies >>> if the database or client crash, or with partitioning? >>> >>> Or alternately: is this merely a design that worked in transactional >>> dbs but doesn't translate to something like CouchDB? If so, what's >>> the recommended way to handle things like this? >>> >>> Thanks! >>> >>> On Wed, Nov 11, 2009 at 6:14 PM, Zachary Zolton >>> <zachary.zol...@gmail.com> wrote: >>>> You COULD use the User document's ID to ensure uniqueness. The second >>>> PUT to the same database URL would result in an HTTP 409 status code. >>>> >>>> Here it is on StackOverflow: >>>> >>> http://stackoverflow.com/questions/1058258/does-couchdb-support-unqiue-key-constraint >>>> >>>> >>>> On Wed, Nov 11, 2009 at 7:00 PM, Cory Nelson <phro...@gmail.com> wrote: >>>>> Hello, >>>>> >>>>> I'm trying to implement a typical user signup operation: when you >>>>> finally add a user to the database, you want it to have both a unique >>>>> user name, and a unique email. In SQL I'd do something like: >>>>> >>>>> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE >>>>> >>>>> count = SELECT COUNT(*) FROM t_users WHERE name=? OR email=? >>>>> >>>>> if(count == 0) >>>>> { >>>>> INSERT INTO t_users VALUES(...) >>>>> COMMIT >>>>> } >>>>> else >>>>> { >>>>> ROLLBACK >>>>> } >>>>> >>>>> Can anyone give an example of how to achieve the same thing in CouchDB? >>>>> >>>>> -- >>>>> Cory Nelson >>>>> >>>> >>> >> >
