Редактирования материалов в многопользовательской системе

[trent]

Редактирования материалов в многопользовательской системе

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

Вариант 1:
Затем заходит еще один человек, имеющий права на этот материал и внеся изменения сохраняет его. Первый по окончанию редактирования "перекрывает" весь материал.

Вариант 2:
Затем заходит еще один человек, имеющий права на этот материал и внеся изменения сохраняет его. Первому выдается предупреждение, что его материал устарел и надо взять новую версию материала.

Кто как разруливает такие ситуации?
Если есть другие варианты, то прошу их высказать.

 

[PhpDeveloper]

У меня так:
Каждый "материал" принадлежит к/л пользователю. Если пользователь разрешает другим пользователем редактаровать материал, то у него нет никаких гарантий, на то что его материал не будет изменен. Неважно будет ли это "коллизия" во время редактирования, или нет.

Возможно вариант не самый лучший, но претензий пока не было.

 

[confguru]

Оба не правильные ,))

Нельзя давать нажимать - редактировать
если материал заблокируется - на кнопке
нужно присать - редактируется тем-то
тем-то (предусмотреть рефреш страницы
если есть редактируемые материал)

 

[Magz]

Если нет принадлежности к пользователю, то рулится так:
1. Закрывается возможность редактирования.
2. На уровне TimeStamp: кто раньше сохранил, тот и прав.
Можно усложнить: проверять при этом, есть ли пересечение не по записям, а по полям. Но это сильно усложнит структуру базы. Обычно, игра не стоит свеч. Просто пишем, что "запись уже отредактировал такой-то (имя не обязательно, зависит от контингента), загрузите новые данные". Но это уже сервис. Там можно много чего накрутить.

 

[deek]

все уже продумано в современных СУБД.

для этой проблемы существует понятие блокировки -
на уровне записи, и на уровне таблицы.

Magz, с удовольствием посмотрю на СУБД, где реализована блокировка на уровне поля. имхо, это лишняя функциональность. я с трудом погу придумать ситуацию, когда запись _необходимо_ редактировать двум пользователям одновременно.

я считаю, что нужно тупо блокировать доступ к записи до завершения редактирования.

 

[KR]

размышления на эту тему:

[15:55] <KR> можно пробовать вообще урл блокировать, если он уже открыт кем-то
[15:55] <[trent]> блин.. а если чел ушел обедать, а отредактировать надо срочно?
[15:56] <KR> автоматическое закрытие по истечение какого-то времени
[15:57] <KR> например, если файл (и т.д.) пытаются сохранить более, чем через 10 мин, после его открытия, то сохранение не происходит
[15:57] <KR> или что-то в этом роде

естественно, это все прекрасно переносится на ДБ.

 

[Magz]

To deek:
Блокировку на уровне полей легко реализовать в системе, где доступ пользователей разграничивается на уровне полей объекта (кто-то видит только имя-отчество, а кто-то еще и телефон).
Просто закрывать нельзя - а если чел уехал, оставив открытым на редактирование? Пусть не уехал, а внезапно заболел? Не мелкая сошка, пароль к компу которого легко даст админ, а какой-нибудь начальник.... И вот давай извращаться: если десять минут не трогал комп - разблокируем и т.п.

Мне кажется, что решение с помощью TimeStamp является оптимальным. Естественно, на уровне объекта.

 

[confguru]

Есть понятия тайм-аута (самой сессии)
можно ввести таймаут на редактирование
возможно лучше сделать счетчик на жаба скрипте который закроет окно после промежутка времени

 

[Sirius]

Как у Лотуса Домино - делать конфликты.

Один из документов по различным параметрам всё же выбирать как основной, но другой не удалять, и ставить как конфликтный, пока админ не разберётся!

 

[su1d]

просто идея: а нельзя ль туда как-нибудь CVS прикрутить? ведь он разруливает вроде такие ситуации хорошо, а док-ты -- ХТМЛные, т.е. текст.

 

[deek]

> доступ пользователей разграничивается на уровне полей объекта

имхо, при нормализации надо учитывать еще и возможные _роли_ пользователей. именно поэтому иногда стоит разнести имя-отчество и телефон по разным таблицам.

> чел уехал, оставив открытым на редактирование
с трудом могу себе представить подобную ситуацию. компьютеры в офисах по вечерам выключают.

> Не мелкая сошка, пароль к компу которого легко даст админ
зачем пароль? надо раздать его привелегии нуждающимся.

> возможно лучше сделать счетчик на жаба скрипте который закроет окно после промежутка времени

есть еще мысль.
Можно каждые 10 секунд на клиенте выполнять яваскрипт:

i = new Image(1,1);
i.src = "http://somehost/editexpire.php?uid=" + uid + "&recid=" record_id + "&uptime=" + current_time;
i = null;

таким образом можно обеспечить блокировку на момент редактирования записи. если последнее сообщение от клиента устаревает более чем на 60 секунд, можно считать, что соединение с ним потеряно, и снять блокировку.

имхо, идеальный способ блокировки для тонких клиентов.

 

[Scarab]

Автор оригинала: su1d
просто идея: а нельзя ль туда как-нибудь CVS прикрутить? ведь он разруливает вроде такие ситуации хорошо, а док-ты -- ХТМЛные, т.е. текст.

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

 

[Yurik]

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

 

[rudik]

В догонку, для фанатов не ставить блокировку: делаем diff а затем patch версий и каждую при этом добавляем в CVS.

 

[clevel]

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

 

[Creator2000]

Это частный случай - материалы. Мне кажется (я почти не работал с мускулом, только с оракулом), что в мускуле каждому пользователю должно открываться своя датабаза, куда переписывается все, что ему нужно и он там работает. А потом происходит анализ и изменения в центральной датабазе по старшинству времени изменения или важности юзера. Одно дело, если кладовщик редактировал, другое дело - = зам.ген.дира. Я лично собираюсь строить что-то в этом роде. Хорошо бы oбъединить усилия. Кто хочет - [email protected].

 

[sokol]

Автор оригинала: deek
Magz, с удовольствием посмотрю на СУБД, где реализована блокировка на уровне поля. имхо, это лишняя функциональность. я с трудом погу придумать ситуацию, когда запись _необходимо_ редактировать двум пользователям одновременно.

я считаю, что нужно тупо блокировать доступ к записи до завершения редактирования.

Например PervasiveSQL 2000i Server (or 8i)
http://pervasive.com

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

 

[si]

блокировку на уровне записи

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

 

[ONK]

Автор оригинала: si
только не надо забывать что вы имеет дело с http, т.е скрипт выполнился и умер и с ним умрет и коннект и за ним ваша блокировка тоже помрет.

Если использовался постоянный коннект, то блокировка будет висеть до перезапуска сервера.

Другое дело что блокирвку можно эмулировать, достаточно ввести два поля, первое статус блокировано / не блокировано, второе дата блокирвки (для оценки валидности зависшей блокирвки).
Можно поступить хитрее и хранить в одном дополнительном поле массив с историей манипулирования данными (пользователь, дата, действие, текущий статус действия), но это уже фактически реализация CVS .

 

[si]

Если использовался постоянный коннект, то блокировка будет висеть до перезапуска сервера

А кто вам сказал что при следующем запросе вы именно это конект с нужной блокировкой получите ? С pconnect так вообще делать нельзя.