2015-04-07 3 views
1

Как новичок в CouchDB или NoSQL в целом я не могу найти хороший способ обновления двух документов с гарантией того, что оба они обновлены, или ни один из них.Транзакционное обновление двух документов с использованием CouchDB

В моем случае использования в каждом документе есть булев флаг. Чтобы проиллюстрировать это, предположим, что я говорю о документе типа = «гражданин» с логическим атрибутом isKing. Я хочу обеспечить, чтобы ровно один король за раз. Мне становится сложно, когда я хочу изменить короля. Это требует модификации двух документов (для установки isKing = true для нового короля и isKing = false для старого).

Как я могу гарантировать, что у меня не будет двух или нулевых королей после некоторых неудачных параллельных обновлений?

Я думал о bulk update, но это не помогает, так как оно не поддерживает транзакции.

Редактировать: Я видел вопрос Can I do transactions and locks in CouchDB?, но он не касается моего дела. Это также относится к транзакциям в CouchDB, но это то, где заканчивается сходство. Проблема заключается в том, что транзакционное чтение & обновляет один документ, а я спрашиваю о транзакционном обновлении двух документов. Я не нахожу ответы на другой вопрос полезным для моего случая, но если вы думаете, что это дубликат, объясните, почему.

+0

Возможный дубликат: http://stackoverflow.com/questions/299723/can-i-do-transactions-and-locks-in-couchdb –

+0

@ChrisSnow - спасибо за комментарий. Я уже прочитал вопрос, который вы упомянули, прежде чем открывать этот. Я просто не нашел решений, предложенных там, применимых к моему делу. Основное различие заключается в том, что я хочу обновлять сразу два документа. – TMG

+1

Может ли государство принадлежать другому документу, указывающему на нынешнего короля и, возможно, историю королей и т. Д. Или это можно рассматривать как событие, такое как KingElected и KingAbticated и т. Д. – Daniel

ответ

1

транзакционной семантики с Сыпучими Updates

Короче говоря, нет ни одного (дизайн). Однако вы можете попросить CouchDB проверить, чтобы все документы в вашем запросе _bulk_docs передавали все ваши функции проверки. Если даже один не удается, ни один из документов не написан. Вы можете выбрать этот режим, включив в запрос «all_or_nothing»: true.

Ручка проверки ревизии в собственной validate_doc_update функции путем сравнения oldDoc._rev и newDoc._rev.

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

+0

Это интересно. Я читал о all_or_nothing, но предложение сразу после вашей цитаты: «В этом режиме, если все документы пройдут проверку, все документы будут обновлены, даже если это введет конфликт для некоторых или всех документов». что мешало мне исследовать его. Я не думал, что сам справляюсь с управлением конфликтами, используя утвержденную вами проверку. – TMG

+0

Существуют ли какие-либо ограничения или побочные эффекты такой проверки по сравнению с встроенным управлением конфликтами? – TMG

+0

ИМО №. Ваша специальная обработка исправлений никогда не будет выполняться, если режим обработки версии встроенного jn не отключен.И даже если бы это было - просто нужно было реализовать по встроенному эквиваленту. –

Смежные вопросы