couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Ensuring unique attributes across documents?
Date Fri, 13 Nov 2009 16:51:37 GMT
On Wed, Nov 11, 2009 at 10:59 PM, Cory Nelson <phrosty@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!

Another thing to think about is what permanent inconsistencies means
to you. For a user signup workflow, you could use autocomplete
suggestions from a view to help the user pick a unique name and check
if an entered user id exists. Then just submit the form and check a
view if the new account is kosher.

That's obviously racey, but generally it doesn't matter. How often are
you going to have two people trying to signup with the same email
address? And you can resolve race conditions by using the update seq.
Who ever saved first wins. The loser just gets a friendly, "Oops,
someone just registered that email address."

Granted that doesn't prevent replication from ruining things, but how
often do you want to replicate unknown data into the database holding
user info?

And another thought process is, do you really want globally unique
email addresses? Or do you just want to prevent a spammer signing up
thousands of accounts?

Paul Davis

Mime
View raw message