|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Strannic ну что так сразу о печальном. Почему о печальном-то? Печально было б если б выбора не было. А вариант с таблицей, в которую лог складывается и cron'ом раз в пять минут отсылается - тут уже предлагали, он вполне работоспособный и в случае временной неработоспособности сервера. Strannic да об этом я как то не подумал, но.... превое - письмо рано или поздно все равно дойдет до адресата, Сомневаюсь я... При неработающем сервере-то... Скорее всего придется тебе опять же неотправленные письма в стопочку складывать и перепосылать через какое-то время. Те же... то есть тот же лог, только вид сбоку. :( Strannicвторое - сделаю проверку на при возврате письма. А кто его вернет-то? Напоминаю: сервер сдох. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.05.2005, 14:38 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
fynda Strannicвторое - сделаю проверку на при возврате письма. А кто его вернет-то? Напоминаю: сервер сдох. ;) Последний сервак до которого оно дошло вернет его с сообщением что дескать искомы сервер не найден. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.05.2005, 15:22 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
to batis Я болею, завтра наверное поправлюсь и, если хочешь, опишу решение данной проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 10:38 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Ну, вот вариант решения. Заводим специальную Log - таблицу. Вот с такой, к примеру, структурой: Код: plaintext 1. 2. 3. 4. 5. 6. 7.
В момент коннекта к базе получем с сервака текущее значение времени. Запоминаем в Код: plaintext
При изменени данных триггерами пишем значение Moment (текущее значение времени), Operation (удаление/изменение/), Connect_id (идентификатор коннекта), Table_Name (Имя изменяемой таблички), Rec_Id (идентификатор измененной/добавленной/удаленной записи) Вот, при получении эвента о том, что данные поменялись, лезем в эту табличку и выбираем все, что произошло после LastMoment, и, если не нужны данные по изменениям, сделанным тобой лично - то отбрасываем значения с Connect_id = твоему коннекту. Берем с сервака текущее время, запоминаем. Интерпретируем полученные значения. Смыть, повторить. Kull Damned об этом и говорил, вроде. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 11:20 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
FreemanZAV Я болею, завтра наверное поправлюсь и, если хочешь, опишу решение данной проблемы. Опиши плиз и мне интересно. На счет списка активных юзеров по твоей методике работаю - доволен. События с параметрами когда то тоже пытался реализовать через UDF, там один недостаток - события валятся не дожидаясь окончания транзакци, а так работать можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 11:25 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
А насчет кастрирований там - лучше бы, перед тем как холодным оружием махать предложили бы тогда нормальное решение задачи: Данные обновляются несколько раз в минуту, юзер должен видеть таблицу всегда со свежими обновлениями, причем нажимать постоянно на кнопочку для рефреша его заставлять ни как нельзя! Как здесь быть без рефрешей по событию? ИМХО этим (рефрешами) заниматься вполне допустимо, нужно только прицип гранулярности соблюдать. (ограничевать максимальное количество рефрешей в единицу времени) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 11:40 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
ЛебедкинА насчет кастрирований там - лучше бы, перед тем как холодным оружием махать предложили бы тогда нормальное решение задачи: Имхо с кастрацией уже поздно. С родителем надо было разбирацца :) Лебедкин Данные обновляются несколько раз в минуту, юзер должен видеть таблицу всегда со свежими обновлениями Лично мне незнакомы задачи, в которых это на самом деле нужно. Знакомо много народу, искренне уверенного что нужно, но объяснить зачем они не могут. Знакомы также люди, втискивающие в СУБД-приложения несвойственные этим приложениям функции. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 13:02 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Amris MirddinЛично мне незнакомы задачи, в которых это на самом деле нужно. Знакомо много народу, искренне уверенного что нужно, но объяснить зачем они не могут. Знакомы также люди, втискивающие в СУБД-приложения несвойственные этим приложениям функции. Ну возьми, для примера, хотя бы мою задачу: Большой таксопарк. В минуту в БД записывается разными операторами до 10 заявок. Несколько диспетчеров, занимающихся распределением заявок на автомобили непрерывно должны видеть как поступающие заявки, так изменяющейся статус введенных заявок для того, не возникало конфликтов (или было минимальным), когда два диспетчера пытаются распределить одну и ту же заявку. Плюс так же оперативно нужно видеть изменяющийся по статусам (занят, свободен, не на линии) список автомобилей. И я уверен подобных задач реального времени в жизни хватает. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 16:13 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
ЛебедкинИ я уверен подобных задач реального времени в жизни хватает.Я бы для такой штуки делал надстройку - сервер-паблишер, который умеет рассылать нужные мне "эвенты-записи" основываясь на постоянном рефреше (тикер от 3-х секунд - подбирать) парочки-тройки таблиц лога (посменно, чтобы можно было чистить в фоновом режиме) на серверной стороне. А на клиентской стороне приемник-стек. Примерно так. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 16:28 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Лебедкин Ну возьми, для примера, хотя бы мою задачу: Большой таксопарк. В минуту в БД записывается разными операторами до 10 заявок. Несколько диспетчеров, занимающихся распределением заявок на автомобили непрерывно должны видеть как поступающие заявки, так изменяющейся статус введенных заявок для того, не возникало конфликтов (или было минимальным), когда два диспетчера пытаются распределить одну и ту же заявку. Плюс так же оперативно нужно видеть изменяющийся по статусам (занят, свободен, не на линии) список автомобилей. И я уверен подобных задач реального времени в жизни хватает. А я бы не так к решению задачи подходил. Работал бы через трехзвенку. Причем статус автомобилей держал бы в памяти и в базу бы не писал. Каким бы ни был таксопарк при нынешних объемах памяти все его а/м спокойно в память влезут. Так же поступил бы со списком активных заявок. То есть при поступлении новой записывал бы ее в базу, но и оставлял бы в памяти. И вот из памяти AppServer-a и делал бы Refresh состояния на клиентах не мучая-бы при этом сервер. При закрытии заявки соответственно записывал бы ее в базу и удалял из AppServer-a. Нотификацию организовать можно кучей вариантов, опять же не насилуя птичку... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 17:07 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Лентяй[quot Лебедкин] Ну возьми, для примера, хотя бы мою задачу: Большой таксопарк. В минуту в БД записывается разными операторами до 10 заявок. Несколько диспетчеров, занимающихся распределением заявок на автомобили непрерывно должны видеть как поступающие заявки, Гы, таки мой ТЛ в отличной форме даже в понедельник Так и знал, что задача именно эта. Тык вот, ему не нужно непрерывно видеть все поступающие заявки, ему нужно знать что они есть. И даже это не непрерывно, а только когда он (диспетчер) а) idle б) присутствует на рабочем месте. Т.е. евент должен сообщать только о факте появления в базе новых заявок. А уже диспетчер на осоновании этой информации должен самостоятельно инициировать себе рефреш набора именно в тот момент, когда он намерен взяться за новую заявку. И первое, что он должен сделать когда выберет себе строку для обслуживания - осуществить её пессимистическую блокировку и ещё раз отрефрешить именно эту строку персонально, ибо с тех пор, как он её пофетчил, её уже мог а) взять на обслуживание другой (для этого блокировка) и б) оное обслуживание даже вообще завершить (для этого рефреш). И по завершении обслуживания одной заявки безусловно перечитать весь набор, были там эвенты, не были... Насчёт состояния машин присоединяюсь к предыдущим ораторам. 2 Лентяй: помнишь ты меня спрашивал, зачем нужна возможность задавать транзакцию RefreshSQL персонально и управлять ей? Кроме того, что я тебе тогда сказал, ещё и этот случай - совпадение с транзакцией не SelectSQL, а ModifySQL. А бывает, что нужно то так, то этак - когда основной набор рефрешится не всегда целиком, а построчно тоже. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 17:51 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
дык, я к словам Amris добавлю еще что - есть такая хрень, диаграмма состояний. так вот уже из изложенного про таксопарк я вижу, что у диспетчера есть совершенно явная диаграмма состояний, или последовательность действий. предполагаемое: 1. диспетчер обновляет набор для просмотра заявок. 2. выбирает заявку для обработки (возможно сообразуясь со списком находящихся в этом районе машин), БЛОКИРУЕТ ее от захвата другими диспетчерами. 3. начинает работать по заявке. 4. после обработки заявки возвращается к п.1. то есть, нигде тут никаких постоянных рефрешей нет, они диспетчеру вообще на дух не нужны (как не нужны _другие_ заявки в момент обработки конкретной, например). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2005, 18:35 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Amris MirddinТык вот, ему не нужно непрерывно видеть все поступающие заявки, ему нужно знать что они есть. И даже это не непрерывно, а только когда он (диспетчер) а) idle б) присутствует на рабочем месте. Ему нужно именно видеть все поступающие заявки, что бы выбрат ь из них ту, с которой он хочет работать. Amris Mirddin Т.е. евент должен сообщать только о факте появления в базе новых заявок. А уже диспетчер на осоновании этой информации должен самостоятельно инициировать себе рефреш набора именно в тот момент, когда он намерен взяться за новую заявку. Так вот вам рефреш на основании эвента. Тока он может принять решение что он будет браться за новую заявку видя текущие заявки, так что рефреш надо делать каждый раз после изменения списка текущих заявок дабы показать ему актуальный список. По поводу блокировок - базара нет. Согласен, так и делаем. kdv 1. диспетчер обновляет набор для просмотра заявок. 2. выбирает заявку для обработки (возможно сообразуясь со списком находящихся в этом районе машин), БЛОКИРУЕТ ее от захвата другими диспетчерами. 3. начинает работать по заявке. 4. после обработки заявки возвращается к п.1. то есть, нигде тут никаких постоянных рефрешей нет, они диспетчеру вообще на дух не нужны (как не нужны _другие_ заявки в момент обработки конкретной, например). В момент обработки текущей, другие заявки не нужны - согласен. Но в даной диаграмме: после пункта 4 постоянно надо выполнять пункт 1, пока не перейдем к 2 (т.е. не начнем работать по какой-либо заявке). Лентяй А я бы не так к решению задачи подходил. Работал бы через трехзвенку. Именно в этом направлении я сейчас и работаю ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 09:39 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Но в даной диаграмме: после пункта 4 постоянно надо выполнять пункт 1 то есть, диспетчер сидит сложа руки, и тупо пялится в монитор? Если новые заявки приходят редко, то достаточно сигнала, что появились новые заявки. Жмем кнопку - перечитываем. Если новые заявки приходят часто, то у диспетчера на экране все будет просто мелькать. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 11:50 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
to Лебедкин Рассказываю. Нужно 4 таблицы. В 1-й будет список активных пользователей (подойдет USERS_CLIENT). Во 2-й список событий Код: plaintext 1. 2. 3.
Код: plaintext 1. 2. 3. 4.
Код: plaintext 1. 2. 3. 4. 5. 6. 7.
Код: plaintext 1. 2. 3. 4. 5. 6. 7.
В USERS_CLIENTS сделаем триггер на удаление Код: plaintext
Допустим есть таблица Код: plaintext 1. 2. 3. 4.
Код: plaintext 1. 2. 3. 4. 5.
Код: plaintext 1. 2. 3.
Основная проблема определить, жив-ли клиент, нуждающийся в событии. Если использовать USERS_CLIENT, то проблем нет. Кроме этого есть еще несколько способов это определить, но я че-то уже устал. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 12:06 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
kdvто есть, диспетчер сидит сложа руки, и тупо пялится в монитор? ну он мжет, например, чай пить :-) и время от времени, например раз в 10 сек поглядывать на монитор, при этом ни куда не нажимая kdv Если новые заявки приходят редко, то достаточно сигнала, что появились новые заявки. Жмем кнопку - перечитываем. Если новые заявки приходят часто, то у диспетчера на экране все будет просто мелькать. Ни чего подобного, мелькания даже не заметно. Просто в гриде вдруг появляется новая строка или существующая меняет иконку или цвет (статус) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 12:58 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Лебедкин Лентяй А я бы не так к решению задачи подходил. Работал бы через трехзвенку. Именно в этом направлении я сейчас и работаю Но в этом случае уже вся информационная нагрузка будет на сервер приложений, а InterBase (или любая другая СУБД) будет просто хранилищем архивных данных. Это нормально, но вопрос то ставился про выполение задачи именно средствами IB И что бы тут не говорили про кривое программирование, система на основе рефрешей по событиям реально работает (не без огрехов кончно, а где их нет?), а значит имеет право на жизнь ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 13:06 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Лебедкин Ни чего подобного, мелькания даже не заметно. Просто в гриде вдруг появляется новая строка или существующая меняет иконку или цвет (статус) угу, сел пользователь - прицелился, ткнул дважды в запись - а она возми и поменяйся на другую ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 13:13 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Лебедкин ну он мжет, например, чай пить :-) и время от времени, например раз в 10 сек поглядывать на монитор, при этом ни куда не нажимая Можно обновлять грид по таймеру раз в N (N - настраиваемо) секунд. Сел пить чай - включил таймер, и пусть поглядывает себе. А вообще нефиг чаи расписать на рабочем месте! ;) Лебедкин Ни чего подобного, мелькания даже не заметно. Не заметно или пока не заметно? ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 13:19 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Sash*угу, сел пользователь - прицелился, ткнул дважды в запись - а она возми и поменяйся на другую Тоже не угадал (хотя в первых версиях у меня так было), клинтский датасет перед рефрешем запоминает номер позиции по айдишнику, а после рефреша на него же перескакивает. В результате создается впечатление что при исчезновении строки сверху все строки просто сдвигаются, вместе с прицелом. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 13:25 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
fyndaМожно обновлять грид по таймеру раз в N (N - настраиваемо) секунд. Сел пить чай - включил таймер, и пусть поглядывает себе. А вообще нефиг чаи расписать на рабочем месте! ;) Тогда чем обновление по таймеру лучьше обновления по событитю? fyndaНе заметно или пока не заметно? ;) Уже два с половиной года не заметно ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 13:31 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Да уж, всё это здорово, но вот если бы за Event-ом можно было бы <int > приклеить, то не нужно было бы городить такое как FreemanZAV. Многим, так или иначе приходится подобное выдумывать. Когда я спросил у уважаемых гуру-создателей, почему решили отказаться от возможности высылать эвенты с параметрами, то ответ был простой и главное информативный: "патамучто" :( Хотя есть ряд задач, где действительно проще выслать ID с параметром, чем городить внешние таблицы-логи, таблицы с событиями, таблицы с клиентами и т.д. мне бы эта штука очень даже подошла, хоть у меня нет никакого грида. просто нужно знать какая запись в таблице запись изменилась. Можно конечно udf написать, которая по отдельному порту по TCP пакетик высылает с ID записи и на триггер повесить, но это тоже изврат нехилый - отдельный коннект на такую штуку держать... Короче, объясните мне, кто может, в чём я ошибаюсь и почему параметр в эвенте является вселенским злом? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 13:49 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
to АВП Ну вот опять. Если миллион записей вставляем, куда складывать параметры до комита и в какой форме давать параметры клиенту. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 13:54 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Лебедкин Тогда чем обновление по таймеру лучьше обновления по событитю? Смотря как часто eventы приходят. Если за эти N секунд, что юзер на экран не смотрит - их десяток наваливается, то перечитываться запрос реже будет. Если за N*10 - один event, то ничем, хуже даже. Просто изначально вопрос был "как тут без event'ов", ну я и выдал идею, _как_. А _надо ли_ - это отдельный вопрос. ;) Лебедкин fyndaНе заметно или пока не заметно? ;) Уже два с половиной года не заметно А, ну тогда конечно "работает - не трогай" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 14:01 |
|
Вопрос по POST_EVENT
|
|||
---|---|---|---|
#18+
Лебедкин Sash*угу, сел пользователь - прицелился, ткнул дважды в запись - а она возми и поменяйся на другую Тоже не угадал (хотя в первых версиях у меня так было), клинтский датасет перед рефрешем запоминает номер позиции по айдишнику, а после рефреша на него же перескакивает. В результате создается впечатление что при исчезновении строки сверху все строки просто сдвигаются, вместе с прицелом. ну так это если он в кнопку редактировавать жмет, а если он дважды щелкает на третей сверху строке - то она еще как из под курсора может выскочить ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2005, 15:25 |
|
|
start [/forum/topic.php?fid=40&msg=33091218&tid=1562165]: |
0ms |
get settings: |
12ms |
get forum list: |
13ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
52ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 174ms |
0 / 0 |