Механизм отката операций

[chi]

На днях возникла следующая мысля на тему отката операций. Охота получить порцию критики о целесообразности таковой.
Идея следующая:

Принцип действия механизма основан на возможности журнализации базы данных средствами Axapta. В связи с этим для использования механизма необходимо, чтобы была активирована лицензия «Database Log», и включен конфигурационный ключ «Журнал базы данных». Помимо возможности журнализации базы данных здесь также используется механизм трассировки SQL-запросов. Перед началом операции, для которой впоследствии может потребоваться возможность отката, включается трассировка SQL-запросов и журнализация тех таблиц, в которые вносятся изменения в процессе выполнения операции. Список таблиц для каждой операции берется из таблицы 1 (изначально она пуста). По окончании операции отключаются механизм трассировки SQL-запросов и журнализация базы данных. Необходимым условием является, чтобы операция не содержала вывод каких-либо диалоговых окон (исключая infolog об окончании операции и Progress Operation).
Далее анализируется набор выполненных SQL-запросов. Если в процессе операции были выявлены изменяемые таблицы, которые не присутствуют в таблице 1, то они вносятся в эту таблицу. В этом случае откат по этому конкретному экземпляру операции будет невозможен. Однако в таблицу 1 будут внесены все необходимые таблицы, чтобы обеспечить откат при последующих выполнениях этой операции. Если в процессе анализа SQL-запросов новых таблиц не выявлено, то из таблицы SysDatabaseLog в таблицу 2 копируются записи SQL-операций, влияющих на изменения в таблицах базы данных. В эту же таблицу копируются модифицированные записи всех таблиц (***).
Далее при необходимости отката выполненной операции из таблицы 2 в обратном порядке изымаются записи, и выполняются действия обратные тем, что указаны в таблице 2. (т.е. если была операция insert, то выполняется delete [это не всегда - исключения ниже]). Перед выполнением отката записи всех таблиц, участвующих в операции, проверяются на эквивалентность тем, что сохранены на шаге *** (см. выше) , указанных в таблице 2 на момент совершения операции. Если соответствия нарушены, то откат будет невозможен. Этим достигается невозможность отката, если после операции была выполнена другая операция, которая повлекла за собой изменения в тех же записях, что и первая операция.
Исключением здесь являются таблицы LedgerBalancesTrans и LedgerBalancesDimTrans.

Надеюсь объяснил понятно.
Ваше мнение.

[AndyD]

А как быть в случае, если в последующих операциях запись не изменялась, но использовалась ссылка на нее? При удалении мы получим нарушение ссылочной целостности.

Да и как вы собираетесь хранить дубли записей? Проще уж считать контрольные суммы, например MD5 или CRC32.

[chi]

Цитата:

Изначально опубликовано AndyD
А как быть в случае, если в последующих операциях запись не изменялась, но использовалась ссылка на нее? При удалении мы получим нарушение ссылочной целостности.

Согласен, что данный механизм не универсален. Нужно ограничить область его применения. Я пока его испытал при разноске журналов.

Цитата:

Да и как вы собираетесь хранить дубли записей? Проще уж считать контрольные суммы, например MD5 или CRC32.

Дубли записей хранить также как это делается в SysDatabaseLog - в контейнере.

[AndyD]

Цитата:

Дубли записей хранить также как это делается в SysDatabaseLog - в контейнере.

В результате - раздувание базы данных.

Кроме того другие прелести - торможение операций, дополнительная нагрузка не сеть

[chi]

Цитата:

Изначально опубликовано AndyD

В результате - раздувание базы данных.
Кроме того другие прелести - торможение операций, дополнительная нагрузка не сеть

Механизм можно использовать не при всех подряд операциях. А только при определенных, для которых желательно иметь возможность отката. Журнализация и трассировка будет включена не постоянно.

[MironovI]

По-моему слишком громоздко и тяжело в администрировании и написании для операции которая будет использоваться в очень ограниченном круге задач.
В Аксе все кругом расчитано на то, что ничего не откатывается. Допустим откатить журнал складской конечно можно, но для этого неплохо бы проверить что период не блокирован, склад не закрыт, на основании этого журнала не выписаны маркировкой другие журналы и т.д. и т.п.. а данный "хирургический" метод цинично напилюет на все это, если ты конечно не потрудишься это учесть, а это опять програмирование.. для топорового метода кстати - есть прога которая оперируя со скулевым транзакшн-логом выборочно откатывает транзакции

[chi]

Цитата:

Изначально опубликовано MironovI
В Аксе все кругом расчитано на то, что ничего не откатывается. Допустим откатить журнал складской конечно можно, но для этого неплохо бы проверить что период не блокирован, склад не закрыт, на основании этого журнала не выписаны маркировкой другие журналы и т.д. и т.п.. а данный "хирургический" метод цинично напилюет на все это, если ты конечно не потрудишься это учесть, а это опять програмирование.. для топорового метода кстати - есть прога которая оперируя со скулевым транзакшн-логом выборочно откатывает транзакции

Хороший аргумент. Нужно подумать.

чувак явно злоупотребляет психоактивными препаратами

[itfs]

Не очень понятно, что будет если над одним объектом последовательно совершаются 2 и более транзакций, а откатить вы хотете первую из них. Состояние объекта на этот момент ни о чем уже не говорит. Придется делать очередь, откатывать их в обратном порядке, потом накатывать то, что откату не подлежит ... транзакционная целостность штука оч. громоздкая, в результате вы получите свою субд процентов на 80 ...

PS. Я тут недавно писал индесный поиск для врем. структур своего формата ... эта задачка гораздо проще, но впечатлений хватило ... так что не советую.

С уважением, itfs.

[mit]

Цитата:

Изначально опубликовано ahtoh
чувак явно злоупотребляет психоактивными препаратами

2ahtoh выбирайте пожалуйста выражения. правила настоящего форума п. 4.1.
2chi в целом идея интересна, но думаю, что практического применения не имеет. гораздо проще написать механизмы отката для конкретных операций, чем писать и поддерживать такой универсальный механизм. Думаю, что приведенные выше ситуации тому подтверждение, конечно, если ваша кампания не пожалеет денег на такую разработку

[chi]

Цитата:

Изначально опубликовано mit
2chi в целом идея интересна, но думаю, что практического применения не имеет. гораздо проще написать механизмы отката для конкретных операций, чем писать и поддерживать такой универсальный механизм. Думаю, что приведенные выше ситуации тому подтверждение, конечно, если ваша кампания не пожалеет денег на такую разработку

Спасибо. Идея как раз и родилась на предложение руководства о разработке возможности отката операций.

2mit и что, я ж его нигером не обзывал вроде, в чем ты там увидел нарушение то?

[mit]

В таком случае Вам придется очень много программировать, я бы даже сказал очень очень много. причем не факт, что разработанный Вами механизм будет поддерживаться на следующих версиях продукта. Для откатов же операций, все таки лучше использовать стандартные механизмы откатов. это как минимум позволит прежде всего тому же руководству найти концы по любой операции. Исключается возможность обмана и мошенничества со стороны пользователей, а это поверьте, существенное преимущество системы, И в первую очередь - для управленческого персонала. Просмотр данных же можно организовать как в полном объеме, так и только тех операций, которые не подверглись корректировкам.

[chi]

Цитата:

Изначально опубликовано mit
В таком случае Вам придется очень много программировать, я бы даже сказал очень очень много..

Это хорошо. Не в плане, что я люблю очень-очень-очень много программировать. Просто начальство хотело, чтобы кто-нить поизучал возможность отката в системе и выдал рез-тат (не обязательно положительный). У меня в кач-ве промежуточного рез-тата было решение, указанное выше. В нем я не привязывался к функционалу, а действовал "хирургически" (термин процетирован от Mironovl;-). Но все оказалось не так просто...

[mit]

было обсуждение на эту тему, почитайте вот это

[chi]

Цитата:

Изначально опубликовано mit
было обсуждение на эту тему, почитайте вот это

Это я видел. Нужно было более глобально рассмотреть.