Разрешение конфликтов CouchDB
Как делает конфликты дескрипторов CouchDB при выполнении двунаправленной репликации?
Например: Позволяет говорят, что существует две базы данных адресной книги (в сервере A и B). Существует документ для Jack, который содержит контактную информацию Jack.
- Сервер A и B копируется, и у обоих есть та же версия документа Jack.
- В сервере A, обновляется номер мобильного телефона Jack's.
- В сервере B, обновляется адрес Jack's.
- Теперь, когда мы делаем двунаправленную репликацию, там конфликт.
То, как делает couchDB, обрабатывает его? Если мы инициируем репликацию в программе Java, есть ли способ знать, были ли какие-либо конфликты из программы Java?
1 ответ
Документация CouchDB предлагает объяснение.
В двух словах: CouchDB не пытается объединить конфликтующие версии. Обе версии копируются в обе реплики. Детерминированный (но с точки зрения приложения, вероятно, произвольный) алгоритм выбирает один из них в качестве «официальной» версии. Он выберет одну и ту же версию на обеих репликах. Только эта версия будет видна по умолчанию и в представлениях. Ваше приложение может запрашивать другие версии и объединять их в соответствии со своими потребностями (возможно, с участием пользователя, показывая все версии на экране). Если ваше приложение не ищет конфликты, одно из двух обновлений будет потеряно.
Если вы не используете API репликации или массовой загрузки (но REST API для отдельных документов), конфликтующее обновление не попадет в базу данных, но будет отклонено с ошибкой 409. Вы должны выполнить слияние перед повторной попыткой обновления (как и в Subversion).