Timestamp момента генерации item

[IgorB]

Да нет никакой таблицы последних времен (свят-свят). Есть таблицы history для разных типов айтемов, а в них timestamp в unixtime и поправка к нему в наносекундах для каждого значения айтема. Не надо понимать "Checking for no data received" столь буквально.

Т.е. вычисление функции - это простой запрос типа SELECT max(clock) FROM history WHERE itemid=123456 ? Тогда причем здесь какой-то таймер, срабатывающий раз в 30 секунд? И ограничение на параметр? И мешок случаев, когда эта функция дает ошибку?

[Semiadmin]

Раз в 30 секунд этот запрос выполняется, это хардкод. Соответственно, и интервал наблюдения не может быть меньше интервала опроса, иначе часть значений можно просто не увидеть. Больше - может.

[IgorB]

Т.е. раз в 30 секунд делается запрос вида SELECT itemid, max(clock) FROM history GROUP BY itemid, и результат таки сохраняется куда-то. Вот она и временнАя таблица, существование которой я и предполагал. А по ней уже вычисляется функция. Я всех выведу на чистую воду! :-)

Возвращаемся к описанной ситуации - куча айтемов в очереди на обработку. В процессе обработки срабатывает таймер и обновляет эту временнУю таблицу. И... Ну... Э-э-э... Тогда да, если айтемы обрабатываются строго последовательно, то проблем вроде быть не должно. А они точно строго последовательно обрабатываются? :-)

[Semiadmin]

Если уж так хочется добраться до сути процесса, то есть еще такая штука, как value cache. Но это несколько иное. А запрос - это и есть часть работы триггерной функции. Select, анализ результата, и как следствие - возможная смена состояния триггера и генерация события.

[IgorB]

Да нет, не так чтобы очень. Просто желательно представлять себе - какова вероятность того, что этот прием даст какие-то ложные срабатывания в особых условиях. Практически нулевая, или все-таки вполне вероятно.

Ну, наверное, вопрос можно считать закрытым. Спасибо за помощь!

[Semiadmin]

Правда, в нашем случае nodata - не единственное условие, поэтому триггер будет пересчитываться не только раз в 30 с, но и при получении значения, об этом позаботится первое условие триггера. Только nodata посчитает, что значение не новое, ибо timestamp древний. И итоговое условие триггера, таким образом, окажется ложным.