2010-05-07 8 views
3

Я видел функцию в различных веб-приложениях, включая Wordpress (не уверен?), Которая предупреждает пользователя, если он открывает статью/сообщение/страницу/независимо от базы данных, в то время как кто-то другое редактирует одни и те же данные одновременно.Запретить двум пользователям редактировать одни и те же данные

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

Это идет немного что-то вроде этого:

1) User A входит страницы при редактировании таинственной статьи X. В таблице Events базы данных запрошены, чтобы убедиться, что никто не редактирует ту же страницу для момент, к которому никто не относится. Затем токен генерируется случайным образом и вставляется в таблицу базы данных, называемую Events.

1) User B также хочет, чтобы сделать обновление к статье X. Теперь, так как наш User A уже редактируют статью, то Events таблица опрашивается и выглядит следующим образом:

| timestamp | owner | Origin  | token  | 
------------------------------------------------------------ 
| 1273226321 | User A | article-x | uniqueid## | 

2) Отметка в настоящее время проверено. Если она действует и меньше, чем, скажем 100 секунд назад, появляется сообщение, и пользователь не может вносить изменения в текст статьи X:

Warning: User A is currently working with this article. In the meantime, editing cannot be done. Please do something else with your life. 

3) Если пользователь А решает пойти дальше и сохранить свои изменения, маркер публикуется вместе со всеми другими данными для обновления базы данных и переключает запрос на удаление строки с помощью токена uniqueid##. Если он решает сделать что-то другое вместо того, чтобы совершать свои изменения, статья X будет по-прежнему доступна для редактирования за 100 секунд для User B

Позвольте мне знать, что вы думаете об этом подходе!

Желаю всем отличного выходного дня!

ответ

0

Выполняет ли редактирование изделие всегда менее 100 секунд?

+0

Ну нет, задержка в 100 секунд была всего лишь примером, так что это может быть немного нереалистично при сложном обновлении статьи. Как бы вы это сделали? – Industrial

+2

Не имеет значения, взяли ли вы 100 секунд как «просто пример». Дело в том, что не существует ни одного такого промежутка времени, о котором вы можете смело сказать: «По прошествии этого времени я могу быть уверенно уверен, что этот редактор больше не редактирует эту статью» (И это освободит статью в разумное время для редактирования для последующих редакторов, которые хотят сделать над ним настоящую работу). То, что вы хотите сделать, имеет большое сходство с тем, что «оставляющие блокировки ожидаются, пока транзакция ожидает ввода пользователя». И это считается очень плохой технологией проектирования. –

+0

Seb предложил возможность «блокировки взлома», то есть возможность для B заблокировать блокировку A без явного удовлетворения согласия A. Вы можете это сделать, но в некоторых случаях все может стать своего рода соревнованием по боксу между конкурирующими пользователями. Предоставление третьим сторонам просто «разбить» то, что я делаю, даже не уведомив меня, не является также самым политическим решением. –

3

Да, это здорово и должно хорошо работать.

Кроме того, я бы добавил, чтобы пользователь B сломал замок - если это вообще нужно!

То есть, есть возможность заменить замок A на B. Таким образом, вы можете избежать временного сдержанности, и они увидели бы «Эй, это редактируется А, и эта блокировка составляет XXX секунд/минут. Вы хотите разбить этот замок? ».

С хорошими пользователями (то есть без вредоносных администраторов) этот подход может быть лучше, чем иметь всего 100 секунд, чтобы что-то редактировать - иногда вам просто нужно больше времени.

+0

Привет, Seb, это отличная идея, которую я действительно должен реализовать. Спасибо чувак! – Industrial

2

Звучит так, как будто все будет хорошо. Если вы хотите денормализовать это и удалить дополнительную таблицу Events, просто добавьте поле UserId и Timestamp в таблицу Articles, так как это все, что вам действительно нужно.

Вы можете легко проверить, не соответствует ли UserId, и если Timestamp менее 100 секунд, то отобразите сообщение.

Таким образом, вам не нужно делать никаких удалений на отдельной таблице.

2

Я бы добавил, что вы могли бы запустить огонь запроса AJAX каждую минуту или около того, если что-то было сделано на странице, чтобы обновить метку времени.

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