События с параметрами

[WildSery]

решить введя ограничения на "массовость" сообщений в одной транзакции.

Вводить вообще нужно осторожно, не важно что и куда.
Как ты это представляешь? 100 можно, а 101 нельзя? И куда оно денется - не пошлётся? А клиент-то не узнает, влезло или нет

ИМХО никогда клиенту не нужно знать обо всех изменениях в базе на сервере. От таких евентов один трафик сетевой бесполезный генерируется.

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

[Merlin]

Приводить реальную задачу не хочу.

Ясна. Как всегда, просто позведеть вышел.

Остается только реализовать эту возможность в Firebird

Ога. А ещё луччи, чтоб сервак сам отыскивал в приложении вызуальные компоненты, в которые энто надо фтыкать, и в какое место, гриды там раздвигал бы и так далее. Без ID мы уже выборку ну никак ограничить не можем, ни по таймштампу, ни по логу изменений в действительно критичных приложениях, завсегда селект * фром табле и фсё тут.

[ivl]

Иногда мне кажется, то что здесь пишут другие, некоторые просто не читают. .

Вводить вообще нужно осторожно, не важно что и куда.
Как ты это представляешь? 100 можно, а 101 нельзя? И куда оно денется - не пошлётся? А клиент-то не узнает, влезло или нет.

Даже в таком подходе есть нормальность. Например последние 100 или 101 и вообще это можно параметризовать. Если кому-нибудь было бы интересно, я бы предложил бы и разумные варианты.

Приводить реальную задачу не хочу.

Ясна. Как всегда, просто позведеть вышел.

Я не собирался обсуждать здесь реальных задач т.к. мне не нужен совет по их реализации. Я хотел высказать только свое мнение о применимости определенной особенности на практике и её полезности. Я его высказал.

Ога. А ещё луччи, чтоб сервак сам отыскивал в приложении вызуальные компоненты, в которые энто надо фтыкать, и в какое место, гриды там раздвигал бы и так далее. Без ID мы уже выборку ну никак ограничить не можем, ни по таймштампу, ни по логу изменений в действительно критичных приложениях, завсегда селект * фром табле и фсё тут.

А вот выше настоящий "звездешь". Я совета как писать приложения в данной теме не спрашивал. А написанное выше расцениваю просто как нездоровый консерватизм.
Насколько я понимаю, форум это место для обмена мнениями, идеями и наделять его исключительно функцией, где некто "умный" поучает других, думаю, неразумно.
Никого не хотел обидеть.
За сим прощаюсь и оставляю последнее слово за вами (хотя не верю в то, что оно будет по смыслу).

[kdv]

Я хотел высказать только свое мнение о применимости определенной особенности на практике и её полезности. Я его высказал.

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

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

такой "отход" позволяет оппонентам только убедиться в правильности своего мнения. конкретно, что параметризированные события ВРЕДНЫ.

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

[Kotъ-Begemotъ]

Лично для меня смысл термина "сразу" означает именно сразу как изменились, а ни когда он что-то закончил делать. И дело тут совсем не в "скачущих" гридах, коих в клиенте может вовсе не быть. А в измененных данных, важность которых может превышать сам процес действий пользователя. Порой с данными которые изменились важно не только что-то делать, а и знать что именно и на что изменилось.

Пример в студию плиз. В смысле описание реальной задачи из реальной предметной области.

А легко!
Менеджер такси. Окно парка ("квадратики" водителей цветом различаются состояния, задан позывной, длительность нахождения в последнем (текущем) состоянии, состояние (свободен, выполняет заказ, межгород, етк.) и куча дополнительных пометок в зависимости от соответствующих полей в базе.
Окно заказов - тут понятно, номер заказа, адрес, и прочее...
Есть диспетчеры на телефонах, принимающие заказы, есть на рации(ях) отдающие. Последние являются не просто "дрессированными обезьянами", а фактически менеджерами, так как не просто тупо отдают заказы, а "рулят" парком (как, это будет тут избыточной информацией). Так вот. Территориально диспетчеры обоих типов разнесены по разным помещениям. Поступил заказ, диспетчер на телефоре его набил. Заказ тут же должен увидеть диспетчер на рации, отдать его таксисту. Диспетчер на телефоне должен тут же увидеть что заказ отдан, чтобы назвать клиенту машину и время подачи. Более сложный случай - поступил "VIP заказ" диспетчер на телефоне его набил. Диспетчер на рации видит, пытается отдать - нет машин VIP класса. На заказ ставится определённая пометка, которая должна сразу (а не через 10-15-20 секунд, в течении которых клиент висит на телефоне и ждёт) появиться в окне заказов у диспетчера на телефоне. Тот видит, что нет VIP машин, сообщает об этом клиенту. Если клиент соглашается на "Не VIP" машину, "цепочка" пошла дальше. Диспетчер на телефона снимает эту пометку что нет машин этого класса с заказа. Диспетчер на рации видит пропадание пометки, и отдаёт заказ любому водителю. Соответственно диспетчер на телефоне сообщает клиенту машину и время подъезда машины).

Ну как реальная задача? Можно здесь ждать по 15 секунд на каждом этапе, или получать обновления данных нажимая "волшебную кнопку"?

[WildSery]

Ну как реальная задача? Можно здесь ждать по 15 секунд на каждом этапе, или получать обновления данных нажимая "волшебную кнопку"?

Как тебе сказали в соседней ветке, задача - реальная, реализация - плохо.
Если не хватает обновления по нажатию кнопки с подсказкой, что новьё есть, добавь ещё таймер, который будет включаться, скажем, через минуту бездействия ползателя, и каждые 15 секунд нажимать кнопку самостоятельно при наличии изменений.

[Kotъ-Begemotъ]

Ну как реальная задача? Можно здесь ждать по 15 секунд на каждом этапе, или получать обновления данных нажимая "волшебную кнопку"?

Как тебе сказали в соседней ветке, задача - реальная, реализация - плохо.
Если не хватает обновления по нажатию кнопки с подсказкой, что новьё есть, добавь ещё таймер, который будет включаться, скажем, через минуту бездействия ползателя, и каждые 15 секунд нажимать кнопку самостоятельно при наличии изменений.

А тебе не кажется что как раз такая реализация и будет плохой? Ты же не смотришь фильмы покадрово, нажимая кнопку "следующий кадр"? Есть изменения, они должны отобразиться. Зачем возлагать на диспетчера еще и нажатия кнопки?!?


Дальнейшее здесь http://forum.ibase.ru/phpBB2/viewtopic. ... 3088#23088