Single Node CouchDB, Мультифункциональный Doc транзакций

Question

Предполагая, есть validate_doc_update функция, в конструкторском документе, определяется как:

{ 
    "_id": "_design/ddoc", 
    "_rev": "12-133b5dad579f872884a9ccd6d4be5ee9", 
    "language": "javascript", 
    "validate_doc_update": "function(newDoc, oldDoc, userCtx) { 
     if (oldDoc._rev != newDoc._rev) { throw('FAILED') } 
    }" 
} 

Если выполнить обновление насыпной (_bulk_docs); является ли он транснациональным для нескольких документов?

Примечание: Я нашел this ответ и прочитал документы и запустил некоторый тестовый код. И, похоже, это отличный способ совершать транзакции на CouchDB! Но так как я не видел его в других местах (и задавался вопросом, почему?); хотел убедиться, что это не ошибка.

Answer 1

CouchDB dev здесь.

Это не транзакционный, и он по дизайну, даже на одном узле.

Причина в том, что мы не хотим, чтобы какие-либо API-интерфейсы в CouchDB прерывались при переходе от установки одного узла к установке кластера.

В кластере гораздо труднее гарантировать транзакцию с несколькими документами, поэтому CouchDB даже не пытается ее выполнить.

Answer 2

Я хотел бы добавить, что вы можете хранить всю транзакцию в одном документе, а затем просматривать мнения в своих интересах, чтобы показать результаты.

Например, для хранения денежного перевода вместо хранения двух документов, описывающих депозит и снятие средств, храните их как в документе типа «передача», так и затем создайте представление, возвращающее балансы каждой учетной записи.

Или взять пример в question you referred to: Если вы хотите, чтобы в базе данных был только один король, просто используйте документ с _id = 'king' и сохраните всю информацию о короле , Если король изменится, просто измените фактические данные короля в этом документе. Вы столкнетесь с конфликтом, если два клиента попытаются изменить король одновременно. Кстати, это также отлично работает, если вы использовали несколько узлов или несколько реплик, например, для автономных клиентов через PouchDB. В конце концов, вам придется рассмотреть возможность разрешения конфликтов, но по дизайну вы никогда не столкнетесь с двумя королями.

Итак: в зависимости от ваших потребностей соответствующим образом смоделируйте ваши документы. Если вам нужны транзакции, храните каждую транзакцию в виде единого документа.