On Thu, Nov 12, 2009 at 3:06 PM, Jan Lehnardt wrote: > > 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 > -- > Let's remember that document ids are a great way to enforce uniqueness. You just have to remember when you use them, that you should namespace yourself so you aren't incompatible with data-merges (replication) with other systems. So something like com.example.user:jchris instead of just user:jchris Using docids will mean collisions are eventually detected on clusters, which is probably better than using uuids + secondary attributes in a view query. I know this doesn't solve the 2-values problem, but before people get carried away with uniqueness servers etc, do try to think about if you can model it with a single uniqueness constraint. Chris > > >> >> --Zach >> >> On Thu, Nov 12, 2009 at 3:46 PM, Adam Wolff 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 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 >>>> 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 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 >>>>>> >>>>> >>>> >>> >> > > -- Chris Anderson http://jchrisa.net http://couch.io