Enforce > 1 attribute uniqueness in document

Since there is no unique key constraint concept here, is there a way to enforce for given type of document, > 1 of this document’s field value must be unique (like > 1 unique key constraint on a single RDBMS table)?

For example,

in our bucket there are multiple type of document (which is identified by “_class” attribute value, we are using spring data couchbase framework to manage the couchbase document).

let assume we have a document which of type “user” which have the following fields that need to be unique within the same type of document

  • alias
  • loginName

currently we tried to implement “Unique key check” logic at application level like below (which we feels is not fully safe)

  1. Prior to create new user, we query the bucket for user document which may have alias value OR loginName value match the value of the new user document

  2. If no such document exists, the document creation will proceed.

This logic looks fine until race condition arise. For example,

at time 00000001, 2 doc creation with same alias name take place.
at time 00000004, doc A queries fired to couchbase to check for records with matching alias value (no record found)
at time 00000005, doc B queries fired to couchbase to check for records with matching alias value (no record found)
at time 00000006, doc B creation take place, 1 record created into couchbase data bucket
at time 00000007, doc A creation take place, anther record with same alias value create into the data bucket

So apparently the unique check gatekeeper still have to be at the couchbase server end.

we can’t append the attribute as the document key as we have 2 attributes which by itself must be unique.
existing doc A { “alias”: “abc”, “loginName” : “abc”}

new doc {“alias”: “abc”, “loginName” : “def” } NOT ALLOWED
new doc {“alias”: “cde”, “loginName” : “abc” } NOT ALLOWED
new doc {“alias”: “cde”, “loginName” : “def”} ALLOWED

Any suggestion to workaround these?

Hi, you should work with atomic counter: http://developer.couchbase.com/documentation/server/4.1/developer-guide/counters.html

Thanks for the pointer.

We took a look at the given reference and feel that the atomic counter seems more suitable for case where value generation by apps (e.g. “app key”) that need to maintain uniqueness within the doc in data bucket (we use UUID with spatial info generation to achieve that at application level, since they are multiple copies of app deployed at different nodes where the UUID generation may occur ).

However, our issue above is that the value of document attributes are entered by user which is out of application control.

The application is not allowed to change user entered value but need to ensure these 2 values are unique among the same doc type in data bucket, so appending the automatic counter to achieve uniqueness is not feasible.

Apologies that this got lost in the shuffle and we never responded.

The guidance provided in Can i do unique constraint on some attribute not the id would be the best approach.