Подскажите, как лучше организовать транзакционность, в плане сохранения изменений, если результатом изменений могут разные хранилища. К примеру это может XML файл или СУБД.
У меня задача, примерно, похожа как в 1С конфигурация редактируется.
Я подозреваю, что в 1С все изменения накапливаются в определенной буфере опер. памяти с UndoManager'ом. Затем при нажатии на кнопку "Сохранить", происходит валидация конфигурации, и затем в пределах одной транзакции изменения сбрасываются в БД.
Но в случае с БД понятно, в каждой современной СУБД есть свой менеджер транзакций, а как быть с XML?
Как сохранить изменения в XML с возможностью отката?
Я предлагаю сразу в юмор перенести.
_>Затем при нажатии на кнопку "Сохранить", происходит валидация конфигурации, и затем в пределах одной транзакции изменения сбрасываются в БД.
Вы хорошего мнения о разработчиках 1С.
_>Но в случае с БД понятно, в каждой современной СУБД есть свой менеджер транзакций, а как быть с XML? _>Как сохранить изменения в XML с возможностью отката?
Вы сначала решите, вам "как в 1С" или транзакционность?
С XML все просто. Пишем новый файл с новым XML, переименовываем старый, даем имя старого файла новому, удаляем старый.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[2]: Транзакционность в конфигурации (в стиле 1С)
Здравствуйте, Ромашка, Вы писали:
Р>Вы сначала решите, вам "как в 1С" или транзакционность? Р>С XML все просто. Пишем новый файл с новым XML, переименовываем старый, даем имя старого файла новому, удаляем старый.
Спасибо. 1С предлагаю не трогать Предлагаю отнести мои вопросы к категории "горе от ума"
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, maloi_alex, Вы писали:
_>>Как сохранить изменения в XML с возможностью отката?
W>Транзакционная запись файла
Здравствуйте, Ромашка, Вы писали:
Р>Вы сначала решите, вам "как в 1С" или транзакционность?
А вы знаете как в 1С? Тогда, да, мне это очень интересно!
Re[2]: Транзакционность в конфигурации (в стиле 1С)
От:
Аноним
Дата:
29.01.13 03:35
Оценка:
Здравствуйте, Ромашка, Вы писали:
_>>Затем при нажатии на кнопку "Сохранить", происходит валидация конфигурации, и затем в пределах одной транзакции изменения сбрасываются в БД.
Р>Вы хорошего мнения о разработчиках 1С.
Ответьте же скорее, что мешает быть хорошего мнения о разработчиках 1С ?
_>>Но в случае с БД понятно, в каждой современной СУБД есть свой менеджер транзакций, а как быть с XML? _>>Как сохранить изменения в XML с возможностью отката?
Р>Вы сначала решите, вам "как в 1С" или транзакционность?
Ясно же написано — транзакционность, как в 1С.
Re[3]: Транзакционность в конфигурации (в стиле 1С)
Здравствуйте, maloi_alex, Вы писали:
_>А вы знаете как в 1С? Тогда, да, мне это очень интересно!
С точки зрения БД на примере SQL Server. Версия 8.1. Если верить логам тех. журнала 1С и моей памяти.
Само описание конфигурации хранится в одной из таблиц БД. Все версии конфигурации сохраняются. Если требуется изменение схемы существующей таблицы _tn, то создается новая таблицв _tn_NG. Потом туда кусками по 25-40 записей толкаются записи из старой таблицы. Это делается для всех таблиц, требующих изменения. Когда все записи перенесены, 1С удаляет старую таблицу _tn и переменовывает _tn_NG в _tn. Разумеется, это всё далеко не в одной транзакции происходит. Откат обновления возможен до переименовывания.
Если наврал, то пусть знающие люди поправят.
Re[4]: Транзакционность в конфигурации (в стиле 1С)
Здравствуйте, _ABC_, Вы писали:
_AB>Само описание конфигурации хранится в одной из таблиц БД. Все версии конфигурации сохраняются. Если требуется изменение схемы существующей таблицы _tn, то создается новая таблицв _tn_NG. Потом туда кусками по 25-40 записей толкаются записи из старой таблицы. Это делается для всех таблиц, требующих изменения. Когда все записи перенесены, 1С удаляет старую таблицу _tn и переменовывает _tn_NG в _tn. Разумеется, это всё далеко не в одной транзакции происходит. Откат обновления возможен до переименовывания.
Не лишне упомянуть, что обновление конфигурации, требующее изменения схемы, возможно только после установки монопольного режима доступа (при отсутствии работающих с программой пользователей).
