События.Хотелки. Имеет ли смысл
События.Хотелки. Имеет ли смысл
Допустим необходимо оперативно уведомлять клиента об изменениях
данных.
В существующей реализации можно узнать лишь о том что что-то изменилось и приходится перечитывать всю таблицу.
Хотя на серверной стороне можно указать конкретно какая запись изменилась напр .
POST_EVENT 'CHANGE_TABLE_REC'||'#'||CAST(NEW.PK_FIELD as varchar(32));
Вот если бы сервер отсылал бы уведомления всем клиентам которые ждут событий с именем starting_with('CHANGE_TABLE_REC#') то стало бы возможным перечитать только изменившиеся записи
преобразовав в число то что следует за символом разделителем.
соответственно в fbclient должна быть функция типа isc_wait_all_eventS
данных.
В существующей реализации можно узнать лишь о том что что-то изменилось и приходится перечитывать всю таблицу.
Хотя на серверной стороне можно указать конкретно какая запись изменилась напр .
POST_EVENT 'CHANGE_TABLE_REC'||'#'||CAST(NEW.PK_FIELD as varchar(32));
Вот если бы сервер отсылал бы уведомления всем клиентам которые ждут событий с именем starting_with('CHANGE_TABLE_REC#') то стало бы возможным перечитать только изменившиеся записи
преобразовав в число то что следует за символом разделителем.
соответственно в fbclient должна быть функция типа isc_wait_all_eventS
Re: События.Хотелки. Имеет ли смысл
Даdostap писал(а):Допустим необходимо оперативно уведомлять клиента об изменениях
данных.
В существующей реализации можно узнать лишь о том что что-то изменилось
Нетdostap писал(а):приходится перечитывать всю таблицу.
Думай ещё
Re: События.Хотелки. Имеет ли смысл
[quote="dostap"][/quote]
Что ты должен получить, если изменилось сразу с десяток записей?
Поищи здесь тему про диспетчера такси, там обсуждали некоторые аспекты использования евентов.
Если консерватория правильная, и действительно есть необходимость получать изменения таким образом, я бы отдельную таблицу вёл, куда триггерами заносил все изменения, и посылал уведомление "что-то изменилось". А уже на клиенте лезть туда и выгребать изменения.
Либо даже в самой таблице вести timestamp изменения, и индексно выбирать более свежие запомненного штампа. Только в этом случае удалённые не отследишь.
Что ты должен получить, если изменилось сразу с десяток записей?
Поищи здесь тему про диспетчера такси, там обсуждали некоторые аспекты использования евентов.
Если консерватория правильная, и действительно есть необходимость получать изменения таким образом, я бы отдельную таблицу вёл, куда триггерами заносил все изменения, и посылал уведомление "что-то изменилось". А уже на клиенте лезть туда и выгребать изменения.
Либо даже в самой таблице вести timestamp изменения, и индексно выбирать более свежие запомненного штампа. Только в этом случае удалённые не отследишь.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Ну по-разному можно... Можно и по тем же евентам на добавление/изменение данных, но это не совсем правильно, потому что когда будут работать двадцать-тридцать человек, эвенты будут сыпаться непрерывно, и клиентское приложение "умрёт" так как будет занято только их обработкой.
У меня ситуация такая, что само течение времени является значащим событием, то есть по истечении определённого времени нужно помечать конкретные данные как "устаревшие" и отображать это на клиенте. Поэтому сделал механизм на эвентах, но с контролем по времени. То есть есть еще периодически срабатывающий таймер, который "подбирает" то, что не обработалось в EventAlerter А алертер, в свою очередь обрабатывает поступившие сообщения, после чего делает "задержку" Если в этот момент поступают новые сообщения, алертер выставляет флаг "были необработанные сообщения", и сработавший таймер выполняет их обработку. Если же новых сообщений не было, сработавший таймер ничего не делает. Примерно так. Малость сумбурно, но в целом идея, думаю понятна...
У меня ситуация такая, что само течение времени является значащим событием, то есть по истечении определённого времени нужно помечать конкретные данные как "устаревшие" и отображать это на клиенте. Поэтому сделал механизм на эвентах, но с контролем по времени. То есть есть еще периодически срабатывающий таймер, который "подбирает" то, что не обработалось в EventAlerter А алертер, в свою очередь обрабатывает поступившие сообщения, после чего делает "задержку" Если в этот момент поступают новые сообщения, алертер выставляет флаг "были необработанные сообщения", и сработавший таймер выполняет их обработку. Если же новых сообщений не было, сработавший таймер ничего не делает. Примерно так. Малость сумбурно, но в целом идея, думаю понятна...
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Да я как один из возможных вариантов привёл... А СуперПуперУниверсальных решений давно не ищу. Это всегда занимает неоптимальное время, и всё равно полностью универсально не получается...WildSery писал(а):Ты зарываешься в детали реализации "как уведомить клиента о том, что что-то изменилось".Kotъ-Begemotъ писал(а):
А автору, как я понял, нужно "как получить только то, что изменилось". Чувствуешь разницу?