Народ, а события с параметрами у FB бывают?
Это я ваще. Еще во втором издании "Мир Interbase" 2003 Востриков с Ковязиным напсали такой пример:
POST_EVENT 'MY_EVENT' , 'parameter'; (не дословно).
И написали, что для получения параметров есть функция isc_event_params.
Может это только для линуха? Они ничего не говорят об этом. На винде не работает. В доке для виндового, уже 1.5.4*(и даже сторого) , ничего нету.
Они доку не читали?
События с параметрами
Модератор: kdv
См. ответ dimitr:
http://forum.ibase.ru/phpBB2/viewtopic.php?t=1599
http://forum.ibase.ru/phpBB2/viewtopic.php?t=1599
Ге-ге-гее 
.... Так про объединение security с базой, обещанное во втором, и не спрашиваю.
В "Мир IB" написано, что событие с параметрами УЖЕ реализовано.
И тогда я его долго пытался вызвать из "мира мертвых".
А уж это был бы прорыв. Это вам не булеан, который заменяется 0 и 1. Тут, чтобы реализовать что-то подобное, приходится городить такой огород!... А надо-то всего получить по событию ID-шку измененной записи.
Ну, ясно. Спасибо.
.... Так про объединение security с базой, обещанное во втором, и не спрашиваю. В "Мир IB" написано, что событие с параметрами УЖЕ реализовано.
И тогда я его долго пытался вызвать из "мира мертвых".
А уж это был бы прорыв. Это вам не булеан, который заменяется 0 и 1. Тут, чтобы реализовать что-то подобное, приходится городить такой огород!... А надо-то всего получить по событию ID-шку измененной записи.
Ну, ясно. Спасибо.
Поиск рулит. Если вкратце - делаем безусловный update таблички-миллионника, укладываем этим сервак, который инфу о них должен прихранить где-то за щекой, после этого делаем коммит и укладываем и сетку и клиента миллионом событий. А главное - зачем. 99% желают рефрешить гриды автоматом, вводя юзера в ступор мелькающим и прыгающим экраном во время его действий и независимо от этих действий.
Но это же если у разработчика с головой проблемы. Никто же не заставляет разработчика использовать этот механизм таким зверским образом. Мне кажется странным, что из-за возможности таким образом использовать механизм событий с параметрами, его вообще выкинули.Merlin писал(а):Поиск рулит. Если вкратце - делаем безусловный update таблички-миллионника, укладываем этим сервак, который инфу о них должен прихранить где-то за щекой, после этого делаем коммит и укладываем и сетку и клиента миллионом событий. А главное - зачем. 99% желают рефрешить гриды автоматом, вводя юзера в ступор мелькающим и прыгающим экраном во время его действий и независимо от этих действий.
Дык, собсно, как только начинаем пользовать для передачи ID, так и попадаем в статистическую зависимость от запросов, которые бог кто бог знает когда бог знает как напишет.ivl писал(а): Но это же если у разработчика с головой проблемы. Никто же не заставляет разработчика использовать этот механизм таким зверским образом.
Такой образ - это именно получение ID. Меня лично, в своё время, для более красивого решения некоторых вопросов зело интересовал в качестве параметра не ID и не прочий волюнтаризьм, а строго и жёстко определённый в формате номер транзакции, с которым проблем не возникает. Но хотение было признано достаточно экзотическим, чтобы ломать копья.ivl писал(а): Мне кажется странным, что из-за возможности таким образом использовать механизм событий с параметрами, его вообще выкинули.
Всё это так. Но при наличии нескольких пользователей (больше одного), большом объёме данных в таблице и их относительно редком штучном изменении, передача ID в событии была бы неплохим способом узнать какие записи изменились и выбрать только их не пребегая к дополнительным и порой изощрённым действиям.Merlin писал(а): Дык, собсно, как только начинаем пользовать для передачи ID, так и попадаем в статистическую зависимость от запросов, которые бог кто бог знает когда бог знает как напишет.
Даже для пары пользователей и одном изменении в час бредово.
Событие в лучшем случае должно сказать клиенту "у тебя данные протухли".
А клиент это дело обдумать не торопясь, и если ползатель не возражает, считать данные, либо обновив целиком, либо по таймштампу поля, если это почему-то важно (хотя я чё-та с ходу не придумал, когда важно).
Событие в лучшем случае должно сказать клиенту "у тебя данные протухли".
А клиент это дело обдумать не торопясь, и если ползатель не возражает, считать данные, либо обновив целиком, либо по таймштампу поля, если это почему-то важно (хотя я чё-та с ходу не придумал, когда важно).
А если клиент должен сразу отреагировать на изменения? Если ему вообще не нужны записи, которые не изменялись? Такие ситуации есть и смысла перечитывать всю таблицу я не вижу.WildSery писал(а):Даже для пары пользователей и одном изменении в час бредово.
Событие в лучшем случае должно сказать клиенту "у тебя данные протухли".
А клиент это дело обдумать не торопясь, и если ползатель не возражает, считать данные, либо обновив целиком, либо по таймштампу поля, если это почему-то важно (хотя я чё-та с ходу не придумал, когда важно).
Вот и задумайся над смыслом термина "сразу", а конкретно что для тебя оно означает. Для меня это обычно значит "как только ползатель перестал работать с предыдущей порцией и хочет освежить данные".ivl писал(а):А если клиент должен сразу отреагировать на изменения? Если ему вообще не нужны записи, которые не изменялись? Такие ситуации есть и смысла перечитывать всю таблицу я не вижу.
"Записи, которые не изменялись" - вообще никогда или за последние N секунд? (минут, дней)
Лично для меня смысл термина "сразу" означает именно сразу как изменились, а ни когда он что-то закончил делать. И дело тут совсем не в "скачущих" гридах, коих в клиенте может вовсе не быть. А в измененных данных, важность которых может превышать сам процес действий пользователя. Порой с данными которые изменились важно не только что-то делать, а и знать что именно и на что изменилось.WildSery писал(а):Вот и задумайся над смыслом термина "сразу", а конкретно что для тебя оно означает. Для меня это обычно значит "как только ползатель перестал работать с предыдущей порцией и хочет освежить данные".
"Записи, которые не изменялись" - вообще никогда или за последние N секунд? (минут, дней)
Что касается "N секунд" -- то лично для меня было важно не "N секунд" и не "никогда", а с момента последнего изменения чего-либо подобного. На много проще выбрать в клиент одну запись, чем весь набор.
В своих разработках я безусловно реализовал данную функциональность другими средствами. Но, на мой взгляд, на сколько проще это было бы сделать существуй подобный механизм.
Воспримите это просто как попытку оправдать полезность существования данной возможности в некоторых ситуациях.
Пример в студию плиз. В смысле описание реальной задачи из реальной предметной области.ivl писал(а): Лично для меня смысл термина "сразу" означает именно сразу как изменились, а ни когда он что-то закончил делать. И дело тут совсем не в "скачущих" гридах, коих в клиенте может вовсе не быть. А в измененных данных, важность которых может превышать сам процес действий пользователя. Порой с данными которые изменились важно не только что-то делать, а и знать что именно и на что изменилось.
какие "сразу" - вы смеетесь? Существует 3 (три!) уровня буферизацииА если клиент должен сразу отреагировать на изменения?
1. уровень сервера. "наихудший" - при plan sort в запросе.
2. уровень сервер -> клиент. примерно равен размеру пакета
клиент пока не выдаст все записи пакета "компонентам", сервер не спрашивает.
3. уровень клиентских компонент. буферизация зависит от. самая сильная - clientDataSet.
то есть. пока клиент "отреагирует", буферизация при частых изменениях приведет к тому, что до клиента доедут тыщу раз устаревшие данные.
Забудьте про "реалтайм".
причем, замечу, это никак не зависит от архитектуры сервера - версионник он или блокировочник.
Я не говорил про "реалтайм". 1, 2, 3, секунды -- это не критично. Я просто хотел подчеркнуть, что это не часы, минуты или десятки секунд, и тем более не "по желанию пользователя". И не говорил про частый апдейт, а про избирательность выборки на большом объеме данных с их относительно редким и нерегулярным изменением, но с быстрой реакцией на них. Вот набор характеристик, которые оправдывали бы, на мой взгляд, не просто события с параметрами, но и передачу в качестве параметров именно ID записи, чтобы не гонять по сети большие объемы данных и не прибегать к дополнительным ухищрениям. А использовать такой механизм или нет, по моему дело разработчика.kdv писал(а): то есть. пока клиент "отреагирует", буферизация при частых изменениях приведет к тому, что до клиента доедут тыщу раз устаревшие данные.
Забудьте про "реалтайм".
Приводить реальную задачу не хочу. Я просто сомневаюсь, что обсуждение реальной задачи будет иметь далеко идущие последствия в плане реализации параметров у сообщений.
Всё равно, где мне надо было, я сделал по другому, но с большими издержками.
все равно на клиенте придется перечитывать больше чем нужно было бы.Вот набор характеристик, которые оправдывали бы, на мой взгляд, не просто события с параметрами, но и передачу в качестве параметров именно ID записи, чтобы не гонять по сети большие объемы данных и не прибегать к дополнительным ухищрениям.
в идеале система с передачей событий об изменениях должна быть связана с визуальными клиентскими компонентами, которые при получении события определяют, попадает запись в "окно", видимое пользователем, или в буфер, и перечитывают только ее.
так всегда и заканчивается.Приводить реальную задачу не хочу.
С этим я согласен. Но реализация подобного механизма в компонентах не составляла бы сложную задачу, я так думаю, но всё равно существенно сокращала бы сетевой трафик и размер выборки, упрощала бы программирование, а также размер дополнительной хранимой информации в таблице при использовании разного рода ухищрений для достижения подобного эффекта.kdv писал(а):все равно на клиенте придется перечитывать больше чем нужно было бы.
в идеале система с передачей событий об изменениях должна быть связана с визуальными клиентскими компонентами, которые при получении события определяют, попадает запись в "окно", видимое пользователем, или в буфер, и перечитывают только ее.
Но возможен случай с работой и без явного "окна", формируемого заранее, когда записи начинают выбираться поштучно (с момента запуска приложения).
Недостатки самого подхода отправки сообщений с параметрами можно, на мой взгляд, решить введя ограничения на "массовость" сообщений в одной транзакции.
Остается только реализовать эту возможность в Firebird
