Как обрабатываются конфликты при синхронизации данных в пользовательских приложениях?

Представим, что у нас есть объект D, содержащий некоторые данные. Это изменяется по-разному в двух разных местах, в результате чего возникают объекты данных D 1 и D 2. В зависимости от содержимого D 1 и D 2 могут конфликтовать друг с другом при обратном слиянии в рамках процесса синхронизации.

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

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

Как мне разрешить такие конфликты в приложении, ориентированном на потребителя?


merge algorithm data-synchronization language-agnostic
person user2064000    schedule 25.08.2016    source источник
comment
Именно по этой причине VCS предоставляют пользователям возможность вручную разрешать конфликты. Если нет идентификатора правильности, т. Е. Который должен быть сохранен, а который отклонен, вы не можете сделать это из кода.   -  person vish4071    schedule 25.08.2016
comment
Совершенно верно, и даже тот случай, когда VCS может автоматически объединять изменения, это не означает, что результат не противоречит. Только человек сможет определить связанный ответ.   -  person hlovdal    schedule 27.08.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

1) Очень быстрое слияние обновлений. Подумайте о документах Google - обновления объединяются в реальном времени, когда люди редактируют. Оперативное преобразование (https://en.wikipedia.org/wiki/Operational_transformation) - хороший способ чтобы понять, как именно выполнить такое слияние, но это не должно быть так сложно, как этот документ. Причина, по которой это хорошо работает, заключается в том, что обновлений мало, и вы можете определить, не творится ли кто-то с вашими вещами, прежде чем вложить в них много работы. Вежливость устраняет конфликты - один из вас подождет, пока другой не закончит с этим.

2) Блокировка. Если вы нажмете кнопку редактирования на заметке, заблокируйте ее, чтобы никто другой не мог редактировать ее, пока вы не закончите, и т. Д. Это старая школа, и не такая гладкая, как (1), но она может работать в ситуациях где вы не можете слиться достаточно быстро, чтобы выполнить (1).

3) Разработайте свою модель данных и интерфейс так, чтобы объединенные версии были как можно лучше. Если кто-то может добавлять заметки, но редактировать заметку может только ее владелец, то, например, проблем нет. Или, может быть, вы сможете редактировать мои материалы, только если вы сначала спросите разрешения, и я дам его вам. По мере того, как все становится сложнее, это становится все труднее. Обычно это невозможно сделать хорошо, если вы не готовы жертвовать функциональностью приложения. Однако у вас есть одна вещь на вашей стороне: грубо связываться с чужой работой, поэтому многие вещи, которые вы можете делать, выглядят так, как будто вы их сделали, просто чтобы добиться хорошего поведения, и пользователи будут благодарить вас за них, если вы сделал это с изяществом.

person Matt Timmermans    schedule 26.08.2016