incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Uvarov <>
Subject Re: Validate uniqueness field
Date Thu, 08 Apr 2010 19:52:39 GMT
For single master I have working example of locks implemented as pluggable http handler. It
works similar to rewriter handler.

## Examples

Create a lock with 3 seconds lifetime:

POST http://localhost:5984/DB/_locks?scope=Person&timeout=3000

    201 - { "ok": true, "id": "3adaefg" }
    409 - { "ok": false, "message": "Already exist" }

## Create document

POST http://localhost:5984/DB/_locks/_db/?lock=3adaefg

    { "type": "Person", "name": "John Doe", "login": "John", "email": "" }

If lock does not exist you'll get:

    { "ok": false, "message": "Does not exist" } | { "ok": false, "message": "Expired" }

Note that lock will be released after each POST, PUT or DELETE request (any request is possible,
but GET's does not make sense, just don't point requests to _locks handler).

Validate uniqueness:

  * Lock with scope "Person",
  * Ensure that there is no such person with fields intended to be unique (check email and
login by using views),
  * Create document.

WTF? Convention is a key. You can use any token as scope. For example, if you want to update
a Person, don't lock unless email or login changed.
One lock -- one operation. For multiple documents use Bulk API. Each create/update/delete
will release the lock.
Each lock has a timeout, so you should not be slow, otherwise your update will be rejected.
Define a number of scopes for application and follow conventions.

~300 LOC. I'll push to github if someone interested.

On 29.03.2010, at 22:06, Daniel Itaboraí wrote:

> Distributed uniqueness is a hard problem, but since you intend to use it
> only on a single node, perhaps you should create a view for each set of
> fields that you intend to be unique in your documents.You would emit the
> unique combination of values as the key and the document id as the value.
> For the reduce function, you should just count the number of documents that
> hold that particular key.
> Prior to each PUT or POST on a document, you should query the view to make
> sure that no other document has used that specific combination of values
> (the reduced value should be 0). Also, after each PUT or POST, you´d have to
> query it again to see if the uniqueness still holds (the reduced value
> should be 1).
> If the probability of two or more writers issuing operations that might
> violate the uniqueness constraint is low enough, you might be able to get
> away with it. This, of course, has a race condition (aside from also being
> slow, ugly and discouraged). You would have to periodically handle
> uniqueness violations either automatically or manually.
> I think you should ask yourself first what´s the worst that could happen
> when a violation of a uniqueness constraint happens. Sometimes you can just
> work around it.
> regards,
> Daniel Itaboraí
> On Sun, Mar 28, 2010 at 12:41 AM, faust 1111 <> wrote:

View raw message