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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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