On Jan 11, 2009, at 4:30 PM, Sunny Hirai wrote:
First of all, I'd like to say that CouchDB is an amazing project.
I've been
following it for a year and have recently made it a first class
citizen of
my framework.
Anyways, looked for this answer but I couldn't find it.
Let's say I want to create a database that contains the pages in a
wiki.
Each document looks something like this:
{
name: 'about_us',
body: 'This is the about us page'
}
There would be a view on the database where the key is 'name'.
The problem is this:
User A goes to create the 'aboutus' page. We want it to be unique so
we
check if it is in the view. Since it is the first 'about_us' page,
we can't
find it. So we are about to do the insert but haven't started yet.
In the meantime, User B goes to create the 'aboutus' page. We check
the view
and it also isn't there yet because User A has not completed its
insert. We
start to do the insert for User B.
In this case, both User A and User B have begun the insert process.
At the end of the inserts, we will have two documents with the same
name
'aboutus'. Can this be prevented?
I know I can put the 'name' in the '_id' field but I'd like to avoid
it
because I'm abstracting CouchDB and the abstraction does not allow
for it.
Anybody have any solutions other than making 'name' the '_id' field?
-Sunny
this is what i'm doing:
assume your system will be distributed at some point and that global
uniqueness is hard whether in a rdbms or docms. even auto-increment
will fail here. now take the middle path - only writes need to be
unique because, if all of them are, objects can distribute between
nodes freely (since we already know they are unique inside the system).
so just make a rule - you will require a single couchdb instance to be
available to check uniqueness, but any couchdb instance up to perform
reads or writes which do not need to be unique (like comments with a
timestamp or something).
so host a couchdb at something like
http://domain.org/unique
use this to check the uniqueness of fields. for instance, so see if a
name is in the system try to put
{ '_id' : 'name::yourname' }
or something you app will use to decide the uniqueness of a name in
the system. think of it as a global hash you can check for a given key.
to me this seems quite reasonable, it's a nod to the fact that
distributed uniqueness is very hard, while at the same time accepting
that most applications are difficult to build without it. the
constraint on your system will simply be that the uniqueness server
must be up for some operations to succeed, but if you design for it
many will be able to perform many other operations in the face of a
uniqueness server failure.
my 2cts.
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
