Okay, so if I'm reading this correctly, the procedure should go like this: get next uuid put doc user_email:[email protected] (with reference to uuid) if 409 display email address is already taken else put doc user_name:foobar (with reference to uuid) if 409 delete user_email:[email protected] display user name is already taken else create user doc (with email_address and user_name) display success message
Thanks for your input! —Zach On Tue, Jun 30, 2009 at 6:22 PM, Jason Davies<[email protected]> wrote: > An extension to this scheme would be to add some kind of prefix to the ID, > in case you want to have more than one "uniqueness constraint". So you > might have "user_email:[email protected]" and "newsletter_email:[email protected]" for > example to avoid the two constraints interfering with each other. > -- > Jason Davies > > www.jasondavies.com > > On 30 Jun 2009, at 23:37, Adam Wolff wrote: > >> You can't check then act with couchdb -- there are no transactions. I >> think >> the only way to guarantee uniqueness is to try to put, using the natural >> primary key as the id the of the document. We are doing this by putting a >> document like this:{ >> _id : "[email protected]", >> userId : [reference_to_user_sha] >> } >> >> This way, you can tell if the email address is claimed and take it all in >> one shot. Then it's trivial to create views which accumulate the user data >> as well. >> >> HTH - it took us a while to figure this one out. >> A >> >> On Tue, Jun 30, 2009 at 2:58 PM, Sam Bisbee <[email protected]> >> wrote: >> >>> Greetings, >>> >>>> So, I've got a situation where I want to maintain a CouchDB database >>>> of users that have a user name and email address. Given that the user >>>> name needs to be unique—and is significant to my URL scheme—I've >>>> chosen to use that as the document ID. >>> >>> While I don't know the full context of your situation, I would still use >>> a >>> generated id for users. This makes life much easier in the software's >>> life >>> cycle. For example, what if you want to do away with user names and just >>> use >>> e-mail addresses? Or you need to generically identify a user but don't >>> have >>> access to their user name? Now you need to re-rig your code to use a >>> different id scheme. I've found it much easier to just take the user id >>> generated by the index or my code's logic and use that as my primary >>> identifier in the database. I've found this to be database agnostic. >>> >>>> However, I'd also like to maintain uniqueness of the email addresses >>>> across users... Any ideas about how to best accomplish this? >>> >>> While those with more experience than me on the Couch may have a better >>> technique, I have always just constructed a view that outputs the users' >>> email addresses as keys. Then I can query the view with >>> ?key='emailInQuestion' and if the returned array has any results then the >>> e-mail is already registered. This also scales nicely with cases where >>> users >>> can have more than one email associated to them. >>> >>> -- >>> Sam Bisbee >>> >>> >>> >>> > >
