v8: Парциальная регистрация изменений в базе данных| Как регистрировать не только, какие объекты менялись, но и какие именно реквизиты объектов менялись. | | Автор статьи:
Последняя редакция №1 от 13.07.06
URL: http://kb.mista.ru/article.php?id=288 | |
Ключевые слова: протокол,журнал регистрации,регистрация
Протоколирование.
К сожалению, в стандартном журнале регистрации событий 1С есть возможность только узнать, менялся ли объект, но нет возможности определить, что именно менялось в объекте - какие реквизиты менялись.
Однако можно внедрить в событие перед записью объекта свой обработчик, который будет сравнивать состояние объекта в базе данных с состоянием записываемого объекта и находить различия.
При наличии интереса подобные вещи можно внедрять и в модуль записи набора записей регистра сведений, например, но зачастую движения регистра сведений связаны с состоянием документа-регистратора, поэтому лучше ограничиться контролем записи справочников и документов.
Состояние объекта мы получаем из переменной ЭтотОбъект.
Состояние объекта в базе данных мы получаем с помощью выражения ЭтотОбъект.ПолучитьОбъект().
Изменения объекта получаем через перебор его реквизитов шапки и табличных частей по метаданным.
Изменения объекта можно представить в виде таблицы со структурой Изменения(ИмяРеквизита, ИмяТЧ, СтрокаТЧ, СтароеЗначение, Значение).
Для реквизитов объекта ИмяТЧ=Неопределено.
Для уменьшения объема протокола нужно сохранять только измененные реквизиты.
Однако в протоколе еще должны содержаться время модификации, имя пользователя и другие желаемые реквизиты окружения. Т.е. окружение представляется структурой вида Событие(Время, Пользователь, Компьютер)
Протокол можно хранить в виде справочника, шапка которого повторяет структуру Событие, а табличная часть содержит таблицу Изменения.
Можно поступить иначе, создав два регистра сведений, в одном из них хранятся События, в другом - Изменения.
Можно конечно связать эти два регистра по времени или даже по времени и изменяемому объекту, но один объект может несколько раз меняться в течении одной секунды, поэтому для связи лучше использовать GUID.
Хотя в принципе можно создать один плоский регистр сведений для Событий и Изменений, если не жалко памяти. Здесь мы выигрываем в записи, т.к. запись ведется только в одну физическую таблицу.
Буферизация.
Однако запись данных в протокол при каждом изменении объекта несколько накладно и тормозит работу с базой.
Рассмотрим буферизацию.
При записи объекта изменения накапливаются в глобальной таблице значений.
Периодически эта таблица значений сбрасывается в базу данных и очищается.
Единственный недостаток схемы - приложение может рухнуть, а вместе с ним и буфер.
Можно отслеживать падения, если после сброса буфера в базу данных делать в базе данных запись о том, что стартовал новый буфер. При следующем сбросе эту запись очищать. Тогда зависшие записи будут сообщать нам о несделанных изменениях.
Можно сбрасывать изменения в локальный файл или использовать другие ухищрения виндоус, например область памяти клиента и т.п.
|