[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