Журналирование

Система Ultima Businessware® предоставляет прикладному разработчику опциональную возможность хранить изменения, вносимые в таблицы прикладной схемы базы данных. Логи изменений хранятся в схеме ядра по причине того, что одним механизмом осуществляется журналирование в обеих схемах базы данных. Для этих целей предназначены следующие таблицы:

•LOG_TABLES – журналируемые таблицы;

•LOG_FIELDS – журналируемые поля таблиц;

•LOG_CHANGES – информация об изменениях, совершенных со строками журналируемых таблиц;

•LOG_FIELDS_CHANGED – информация об изменениях, внесенных в журналируемые полях;

•STAT_COMMAND_EVENTS – информация о вызовах методов обработчиков.

Модель данных выглядит следующим образом:

Log_Tables

table В таблице LOG_TABLES хранится перечень журналируемых таблиц:

•OWNER – схема базы данных. Это может быть схема ядра (kernel) или прикладная схема (ultima). Прикладному разработчику доступны для журналирования только таблицы прикладной схемы, соответственно этому свойству автоматически устанавливается значение ultima;

•NAME – название журналируемой таблицы;

•LOGGING – флаг, указывающий журналируется ли таблица. Флаг может быть установлен в значение false, если таблица журналировалась ранее, но впоследствии эта опция была для нее отключена.

35_important

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

table В таблице LOG_FIELDS хранится перечень полей журналируемых таблиц. Механизм журналирования позволяет хранить изменения не всех колонок, а лишь выборочных:

•NAME – название журналируемого поля;

•TABLE_ID (FK) – журналируемая таблица, которой соответствует поле, заполняется автоматически;

•LOGGING – флаг, указывающий журналируется ли поле. Флаг может быть установлен в значение false, если поле журналировалась ранее, но впоследствии эта опция была для него отключена.

table В таблице LOG_CHANGES хранится информация о характере изменений, совершенных со строкой журналируемой таблицы, а также кем и когда они были совершены (заполняется автоматически):

•TYPE – тип изменения, совершенного со строкой таблицы, может иметь следующие значения:

▪I – добавление строки;

▪U – изменение строки;

▪D – удаление строки;

•TIME – время внесения изменений в строку таблицы;

•LOG_ID – идентификатор измененной строки журналируемой таблицы. Присваивается в том числе и самой изменяемой строке таблицы в прикладной схеме базы данных (для этого в ней и было создано аналогичное поле LOG_ID). Идентификатор измененной строки уникален и, будучи присвоенным ей впервые, не меняется с последующими изменениями, вносимыми в содержимое ее полей;

•TABLE_ID (FK) – журналируемая таблица, в строку которой внесены изменения;

•USER_ID (FK) – пользователь, внесший изменения;

•SESSION_ID (FK) – сессия (клиент-сервер), во время которой были внесены изменения;

•CALL_ID – идентификатор вызова (метода), который сохраняет постоянное значение от момента входа в сервер приложений и до выхода.

table В таблице LOG_FIELDS_CHANGED хранятся изменения, вносимые в поля журналируемой таблицы (заполняется автоматически):

•TYPE – тип журналируемых данных, определяет в каком поле таблицы LOG_FIELDS_CHANGED будут хранится изменения, вносимые в содержимое журналируемых полей таблицы. Может иметь следующие значения:

▪N – соответствует полю NUMBER_VALUE;

▪D – соответствует полю DATE_VALUE;

▪V – соответствует полю VARCHAR2_VALUE;

▪C – соответствует полю CLOB_VALUE;

▪B – соответствует полю BLOB_VALUE;

•TIME – время внесения изменений в поле журналируемой таблицы;

•CHANGE_ID (FK) – изменение, совершенное со строкой журналируемой таблицы;

•FIELD_ID (FK) – журналируемое поле таблицы, в которое внесены изменения;

•NUMBER_VALUE – поле, предназначенное для хранения изменений, вносимых в содержимое журналируемого поля числового типа (long, decimal или bool);

•DATE_VALUE – поле, предназначенное для хранения изменений, вносимых в содержимое журналируемого поля типа (date или DateTime);

•VARCHAR2_VALUE – поле, предназначенное для хранения изменений, вносимых в содержимое журналируемого поля строкового типа (string, text и LargeText с длинной не больше 4'000 символов);

•CLOB_VALUE – поле, предназначенное для хранения изменений, вносимых в содержимое журналируемого поля строкового типа (LargeText с длинной свыше 4'000 символов);

•BLOB_VALUE – поле, предназначенное для хранения изменений, вносимых в содержимое журналируемого поля типа byte[].

35_example

Рассмотрим работу механизма журналирования на примере для справочника "Контрагенты":

Log_Example1

Если включить журналирование для его полей NAME, EMAIL и PHONE, в схеме ядра в таблицах LOG_TABLES и LOG_FIELDS добавятся соответствующие записи, а для таблицы AGENTS прикладной схемы будет создано дополнительное поле LOG_ID:

Log_Example2

Теперь при изменении телефона у контрагента "Амелина Алла Леонидовна" в таблицы LOG_CHANGES и LOG_FIELDS_CHANGED схемы ядра, а также таблицу AGENTS прикладной схемы базы данных будут внесены следующие изменения:

Log_Example3

table В таблице STAT_COMMAND_EVENTS хранится информация о вызовах методов обработчиков (заполняется автоматически):

•START_DT – время начала или окончания вызова. Каждый вызов хранится в таблице STAT_COMMAND_EVENTS в двух строках: первой строкой записывается начало вызова, второй окончание. Различаются строки значениями свойств START_DT и DURATION. У первой строки START_DT – это время начала вызова, у свойства DURATION значение отсутствует. У второй строки START_DT – это время окончания вызова, свойству DURATION значение присвоено;

•DURATION – продолжительность вызова;

•HANDLER_OBJ_ID (FK) – обработчик, методы которого были вызваны;

•USER_ID (FK) – пользователь, от имени которого был вызван обработчик;

•SESSION_ID (FK) – сессия, во время которой был совершен вызов;

•SERVER_CALL_ID – идентификатор серверного вызова, который сохраняет постоянное значение от момента входа в сервер приложений и до выхода.