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
