couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ara.t.howard" <>
Subject Re: Can I guarantee uniqueness in a field without using _id?
Date Wed, 14 Jan 2009 01:10:59 GMT

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

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 @
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama

View raw message