couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunny Hirai" <>
Subject Re: Can I guarantee uniqueness in a field without using _id?
Date Mon, 12 Jan 2009 22:17:55 GMT
>  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.
> Why is that?

Amongst other things, the framework can join CouchDB tables to SQL tables.
To allow this to happen, we need to be able to easily share references
through an id field. I use a :bigint like field to handle this. Not
consistently knowing that the id is a :bigint will incur a lot of code
overhead where the code is very clean otherwise. In some cases, we also need
to have uniqueness based on two fields. This would be even harder to store
as the lone _id field, particularly since CouchDB seems to convert all ids
to String.

But, because of the ability to join between two database types, we can use
the database that is the best fit for our needs with more or less the same

For example:

* Where schema doesn't change often and it has to do with transactional
data, we prefer SQL. A good example might be data to do with money
* Where schema needs to be updated often and the data is not very
transactional, we prefer CouchDB. For example, pages in a website. Over
time, we might add tags, or descriptions to those pages. We also might
introduce new page types, some of which support different fields. In this
case, CouchDB is preferred.

Note that models are defined and the API is almost exactly the same between
CouchDB and SQL. The main difference is we define and use "indexes" in SQL
and "views" in CouchDB. It uses similar syntax to Ruby Sequel (and in fact
uses Sequel as a backend for the SQL API).

>  Anybody have any solutions other than making 'name' the '_id' field?
> You'd need some service that acts as global state outside of CouchDB
> that ensures it only allows one client to take a certain name.  CouchDB
> won't do that for you.
> Cheers
> Jan
> --

I wanted to do this automatically somehow. I considered storing unique
values in an outside SQL table just for those unique fields and have it
check automatically against that. Unfortunately, there still seems to be
edge cases that would make this inconsistent. For example, if during the
commit, one or more databases failed. Of course, we could work around those
as well, but now there is a lot of stuff going on to do an insert or update
that messies up the code. I don't like the junk it adds.

Unless anybody can think of a way to guarantee uniqueness in CouchDB, I
think I am going to abandon the notion of GUARANTEED uniqueness and instead
implementcode to PREFER uniqueness. Then at the end of the day, we can write
some code that will tell us if that 1 in a million chance (i.e. two
simultaneous inserts/updates) left our database in a state where there are
two docs with the same unique field.

Since the odds are quite low that it will actually happen, I think we can
deal with the times that it happens manually so long as we know about it.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message