Что я могу сделать, чтобы предотвратить конфликты записи на веб-сайте в стиле wiki?

StackOverflow https://stackoverflow.com/questions/624186

  •  05-07-2019
  •  | 
  •  

Вопрос

Что я могу сделать на веб-сайте в стиле wiki, чтобы предотвратить или смягчить конфликты записи-write сохраняя при этом быструю работу сайта и простоту в использовании?

Проблема, которую я предвижу, заключается в следующем:

  1. Пользователь A начинает редактирование файла
  2. Пользователь B начинает редактировать файл
  3. Пользователь A завершает редактирование файла
  4. Пользователь B заканчивает редактирование файла, случайно перезаписывая все правки пользователя A

Вот несколько подходов, которые я придумал:

  • Иметь какую-то систему извлечения / регистрации / блокировки (хотя я не знаю, как запретить людям проверять файл "слишком долго", и я не хочу, чтобы пользователи расстраивались из-за того, что они не разрешенный чтобы внести правку)
  • Иметь какой- то разница система, которая показывает другие изменения, внесенные, когда пользователь фиксирует свои изменения, и допускает какое-то слияние (но я беспокоюсь, что это будет сложно создать и сделает сайт "слишком сложным" в использовании)
  • Уведомлять пользователей о одновременных изменениях в то время как они вносят свои изменения (какой-то AJAX?)

Есть какие-нибудь другие способы сделать это?Есть какие-нибудь примеры сайтов, которые хорошо это реализуют?

Это было полезно?

Решение

Запомните номер версии (или ID) последнего изменения.Затем прочтите запись, прежде чем записывать ее, и сравните, осталась ли эта версия прежней.

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

Большинство вики делают это таким образом. Медиавики, Usemod Использовать Мод, и т.д..

Другие советы

Трехстороннее слияние: Первое, на что следует обратить внимание, это то, что большинство одновременных правок, особенно в более длинных документах, вносятся в разные разделы текста.В результате, отметив, какие редакции приобрели пользователи A и B, мы можем выполнить трехстороннее слияние, как описано в Билл Ритчер из Guiffy Software.Трехстороннее слияние может определить, где были внесены правки из оригинала, и, если они не противоречат друг другу, оно может незаметно объединить обе правки в новую статью.В идеале, на этом этапе выполните слияние и покажите Пользователю B новый документ, чтобы она могла выбрать его дальнейшую доработку.

Разрешение столкновений: Это оставляет вас со сценарием, когда оба редактора отредактировали один и тот же раздел.В этом случае объедините все остальное и предложите текст трех версий Пользователю B - то есть включите оригинал - либо с версией пользователя A в текстовом поле, либо с версией пользователя B.Этот выбор зависит от того, считаете ли вы, что по умолчанию следует использовать последнюю версию (пользователь просто нажимает Сохранить, чтобы сохранить свою версию) или заставить редактора редактировать дважды, чтобы внести свои изменения (они должны повторно применить свои изменения к версии раздела редактора A).

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

Если вы хотите немного улучшить Ajax, динамически 3-way объедините версию пользователя A в версию пользователя B. пока они его редактируют, и уведомить их.Вот это было бы впечатляюще.

В Mediawiki сервер принимает первое изменение, а затем, когда сохраняется вторая правка, появляется страница конфликтов, а затем второй пользователь объединяет два изменения вместе.Видишь Википедия:Справка: Редактирование конфликтов

Использование запирающего механизма, вероятно, будет самым простым в реализации.С каждой статьей может быть связано поле блокировки и время блокировки.Если время блокировки превысит какое-то установленное значение, вы сочтете блокировку недействительной и снимете ее при проверке статьи для редактирования.Вы также можете отслеживать открытые блокировки и удалять их при закрытии сеанса.Вам также необходимо было бы реализовать некоторый контроль параллелизма в базе данных (возможно, автоматически созданные временные метки), чтобы вы могли убедиться, что вы проверяете обновление до версии, которую вы проверили, на случай, если два человека смогли редактировать статью одновременно.Только тот, у кого правильная версия, сможет успешно выполнить проверку при редактировании.

Возможно, вам также удастся найти механизм различий, который вы могли бы просто использовать для построения различий, хотя отображение их в вики-редакторе может быть проблематичным - на самом деле отобразить различия, вероятно, сложнее, чем создать diff .Вы бы полагались на систему управления версиями, чтобы определить, когда вам нужно отклонить редактирование и выполнить diff.

В Gmail, если мы пишем ответ на электронное письмо, а кто-то другой отправляет ответ, пока мы еще набираем его, появляется всплывающее окно, указывающее на наличие нового обновления, а само обновление отображается как другое сообщение без перезагрузки страницы.Этот подход соответствовал бы вашим потребностям, и если вы можете использовать Ajax, чтобы показать точное сообщение со ссылкой на diff того, что было только что обновлено, пока пользователь B все еще занят вводом своей записи, это было бы здорово.

Как сказал Рави (и другие), вы могли бы использовать AJAX-подход и информировать пользователя о том, когда происходит очередное изменение.Когда будет отправлена правка, просто укажите текстовые различия и позвольте второму пользователю решить, как объединить две версии.

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

Ваша проблема (потерянное обновление) решается наилучшим образом с помощью Оптимистичный Контроль параллелизма.

Одна из реализаций заключается в добавлении версия столбец в каждом редактируемом объекте системы.При редактировании пользователем вы загружаете строку и отображаете html-форму для пользователя.Скрытое поле выдает версию, скажем 3.Запрос на обновление должен выглядеть примерно так: 

update articles set ..., version=4 where id=14 and version=3;

Если возвращаемые строки равны 0, значит, кто-то уже обновил статью 14.Все, что вам нужно сделать тогда, - это как справиться с ситуацией.Некоторые общие решения:

  1. выигрывает последняя фиксация
  2. выигрывает первая фиксация
  3. объединить конфликтующие обновления
  4. пусть пользователь решает сам

Вместо увеличивающегося версия int/long вы можете использовать временная метка но это не предлагается, потому что:

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

(цитата из Сохранение Java в режиме Гибернации)

Еще немного информации на документация по переходу в спящий режим.

В моем офисе у нас есть политика, согласно которой все таблицы данных содержат 4 поля:

  • Созданный с помощью
  • Дата создания
  • Последний день рождения
  • LastUpdateDate Последний день

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

Но самое главное, становится достаточно легко сравнить последнюю дату текущей или отредактированной записи на экране (требуется, чтобы вы сохранили ее на странице, в файле cookie, где угодно, со значением в базе данных.Если значения не совпадают, вы можете решить, что делать дальше.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top