1. Пользователь видит доступные записи (в таблице RECORD поле STAT_ZAP=0)
2. Кликает на запись - открывается окно для ввода личных данных (STAT_ZAP=1, т.е. запись временно занята и ее уже не видят другие пользователи)
3. Либо выбирает "Назад" (снова STAT_ZAP=0) либо "Сохранить" (Cохраняются личные данные и STAT_ZAP=2, запись закреплена за ним)
Проблема в том, что если пользователь закрывает браузер, выключает компьютер и т.д. статус записи может остаться 1, и ее уже не будет видеть никто.
Вопрос в следующем, как посоветуете лучше обрабатывать такие записи.
Мне было предложено написать функцию, которая запускается например, каждые пол-часа и все 1. делает 0. Этот вариант мне вообще не нравится.
Можно ли как-нибудь привязать запись к сессии?. или реализовать только процедурами базы данных (firebird)
Прошу указать направление, в котором копать))
Спустя 1 час, 22 минуты, 26 секунд (26.04.2012 - 05:47) glock18 написал(а):
derkien
Приветствую. Беспорядочно сбрасывать все 1 в 0, действительно, не самая разумная мысль. Могу предложить вам две альтернативы, опираясь на ваши условия:
1. ввести сюда систему оверрайдов, реализуется она несколько сложнее. суть в следующем:
все 1 все равно показываются в списке, но при открытии они закрепляются за открывшим их пользователем, к таким записям добавляется кнопка типа "Запросить доступ", при нажатии на которую в этой записи устанавливается еще одно новое поле - пользователь запросивший доступ (пользователь А).
открывшему запись пользователю (пользователь Б) показывается окошко с тем, что доступ запрошен, и нужно отказать или принять. если ни то, ни другое по истечении времени ожидания пользователя А считается, что доступ переходит к нему, если Б не ответил (Б, вполне вероятно подходит под "закрыл браузер, выключил компьютер и тд").
условие в том, что придется отправлять много ajax-запросов или использовать веб-сокеты, чтобы обеспечить интерактивность этой схемы.
2. нечто среднее - упомянутая функция, запускаемая раз в полчаса, должна менять не все 1 на 0, а опираться при этом на дату изменения записи (возможно, нужно будет добавить поле, и обновлять его timestamp'ом при установке в STAT_ZAP = 1). При этом можете, скажем, не сбрасывать в 0 те строки, в которых дата совсем недавняя (например, в пределах 10 минут), что позволит избавиться от проблем у тех, кто только открыл запись в момент обнуления.
Приветствую. Беспорядочно сбрасывать все 1 в 0, действительно, не самая разумная мысль. Могу предложить вам две альтернативы, опираясь на ваши условия:
1. ввести сюда систему оверрайдов, реализуется она несколько сложнее. суть в следующем:
все 1 все равно показываются в списке, но при открытии они закрепляются за открывшим их пользователем, к таким записям добавляется кнопка типа "Запросить доступ", при нажатии на которую в этой записи устанавливается еще одно новое поле - пользователь запросивший доступ (пользователь А).
открывшему запись пользователю (пользователь Б) показывается окошко с тем, что доступ запрошен, и нужно отказать или принять. если ни то, ни другое по истечении времени ожидания пользователя А считается, что доступ переходит к нему, если Б не ответил (Б, вполне вероятно подходит под "закрыл браузер, выключил компьютер и тд").
условие в том, что придется отправлять много ajax-запросов или использовать веб-сокеты, чтобы обеспечить интерактивность этой схемы.
2. нечто среднее - упомянутая функция, запускаемая раз в полчаса, должна менять не все 1 на 0, а опираться при этом на дату изменения записи (возможно, нужно будет добавить поле, и обновлять его timestamp'ом при установке в STAT_ZAP = 1). При этом можете, скажем, не сбрасывать в 0 те строки, в которых дата совсем недавняя (например, в пределах 10 минут), что позволит избавиться от проблем у тех, кто только открыл запись в момент обнуления.
Спустя 9 минут, 20 секунд (26.04.2012 - 05:56) derkien написал(а):
glock18, спасибо за ответ.
Я склоняюсь больше ко второму предложенному вами решению т.к. первое усложняет работу с интерфейсом для пользователей, а мне важна простота. Они вообще не должны видеть занятые записи. Если нет никаких решений как связать разрыв сессии и обнуление статуса записи, занятой данной сессией, то так и буду делать.
Хотелось просто реализовать следующее: Сессия разрывается (закрыт браузер, выключен комп) - записи, которой присвоен статус 1 в течении этой сессии присваивается 0. Исходя из моих знаний)) проблема в том, что сервер не знает о закрытии браузера на стороне клиента и сессия будет висеть до таймаута. Возможно я заблуждаюсь)
Я склоняюсь больше ко второму предложенному вами решению т.к. первое усложняет работу с интерфейсом для пользователей, а мне важна простота. Они вообще не должны видеть занятые записи. Если нет никаких решений как связать разрыв сессии и обнуление статуса записи, занятой данной сессией, то так и буду делать.
Хотелось просто реализовать следующее: Сессия разрывается (закрыт браузер, выключен комп) - записи, которой присвоен статус 1 в течении этой сессии присваивается 0. Исходя из моих знаний)) проблема в том, что сервер не знает о закрытии браузера на стороне клиента и сессия будет висеть до таймаута. Возможно я заблуждаюсь)
Спустя 7 минут, 14 секунд (26.04.2012 - 06:04) glock18 написал(а):
| Цитата (derkien @ 26.04.2012 - 03:56) |
| Исходя из моих знаний)) проблема в том, что сервер не знает о закрытии браузера на стороне клиента и сессия будет висеть до таймаута. Возможно я заблуждаюсь) |
все верно. ну, браузер может уведомить о закрытии или переходе со страницы (речь о событии unload), но есть пара моментов, которые эту возможность сводят на нет:
1. пользователь оставил сайт открытым и уехал в командировку
2. если пользователь переходит на другую страницу, то невозможно узнать ее адрес, а потому если он даже просто перешел по сайту то, такой переход никак не отличить (без доп. костыльной логики на стороне сервера) от закрытия окна браузера
Спустя 18 минут, 3 секунды (26.04.2012 - 06:22) derkien написал(а):
Да, тогда все-таки второй вариант. Спасибо.