[Devel] Информация для DBServer'а
Evgeny Sinelnikov
sin на etersoft.ru
Чт Сен 16 15:38:16 MSD 2010
16 сентября 2010 г. 14:05 пользователь Ilya Shpigor
<shpigor на etersoft.ru> написал:
>> Да, на придётся добавить поле confirm в таблицу main_history.
>
> Правильно понимаю, что таблица main_confirm нам станет не нужна?
>
Да. Добавил поле confirm в main_history.
Тип Integer. Запись содержит время в милисекундах - разница между
верменем получения события и временем квитирвания. Эту разницу
высылает журнал в сообщении DBServer'у.
>> Компромисс, при этом будет таким. По умолчанию, значение поля confirm
>> равно NULL. DBServer при отправке в базу проверяет нет ли
>> необходимости квитирования датчика по configure.xml (если это тяжёлая
>> операция, то вовремя загрузки делаем std::map<ObjectID,bool>).
>
> Ок, а откуда загружать этот std::map<ObjectID,bool>?
>
Это нужно вычислять. Только вот не совсем так, как я указал. В полном
виде отображение должны быть таким:
std::map<std::pair<ObjectID, long>,bool>
> Нам нужен некий файл настроек или DBServer должен сам распарсить
> configure.xml?
>
Ну, парсить - это пробежаться по configure.xml, чтобы сделать более
быстрый runtime-хеш.
> Не прибивать же в коде: "id датчика" <=> "необходимость квитирования".
>
Не просто id, а std::pair<is,value>. Ну, вот это вычисляется. Как мы
узнаём нужно квитировать или нет?
Мы смотрим, является ли mtype для сообщения не равным нулю (1 -
warning, 2 - alarm). А проверяем по паре <дачтик,значение>.
В принципе, метод выяснения необходимости квитирования вынести бы в
общий алгоритм. Это будет такая характеристическая функция от
SensorMessage (или просто датчика, но ведь это уже обращение к Corba)
и Configure. Тогда код проверки в DBServer и Журнале был бы один и тем
же.
--
Sin (Sinelnikov Evgeny)
Подробная информация о списке рассылки Devel