Как вы гарантируете уникальность поля в документе CouchDB?

Question

Как раз то, что написано на банке. У меня есть (скажем) документы участника, я хочу, чтобы каждый пользователь мог установить в поле «Электронная почта» в своем документе все, что ему нужно, например, электронное письмо, которое существует в другом документе. Если я просто сделаю чек-вставку, я уязвим для состояния гонки. Есть ли какая-то идиома для "блокировки" или вставки, а затем проверки?

Answer 1

Единственный верный способ - создать документ с уникальным значением в качестве идентификатора документа.

Answer 2

Как отмечается в другом ответе, единственное поле, гарантированно уникальное в CouchDB, - это _id.

Здесь вы можете позаимствовать хитрость у репликатора.Для быстрой пересылки второй реплики между теми же двумя хостами он записывает документ контрольной точки, в котором записывается последовательность обновлений, которой он достиг в последний раз.Но как он находит документ контрольной точки в будущем?Примерно так:

"_ id": md5 (source.host + source.port + target.host + target.port)

Можно извлечь общий шаблон, в котором ваши уникальные поля образуют частьсам идентификатор.Запуск их через md5 гарантирует идентификатор фиксированной длины.

В вашем случае вы можете просто использовать адрес электронной почты в качестве своего идентификатора.

Изменение одного из этих полей - двухэтапный процесс, но тот, которыйпо-прежнему поддерживает свойство уникальности.

1. Скопируйте документ в новый идентификатор (http://wiki.apache.org/couchdb/HTTP_Document_API#COPY)
2. В случае успеха удалите старый (http://wiki.apache.org/couchdb/HTTP_Document_API#DELETE)

Сбой между шагами1 и 2 оставят старый документ на своем месте, поэтому вы можете добавить ссылку на старый документ в новый документ. Затем вы можете создать представление этих обратных ссылок и периодически выполнять очистку.

Все это говорит о том, что CouchDB намеренно поддерживает только одно уникальное поле, в отличие от типичной СУБД, которая может поддерживать сложные реляционные ограничения, чтобы обеспечить точное масштабирование решения в кластере (см. BigCouch).где адрес электронной почты должен быть уникальным, многое из того, что я сказал, должно работать (адреса электронной почты меняются не так часто), но, очевидно, этоплавание вверх по течению до степени.

HTH, B.