Как откатить изменения, сделанные несколькими вложенными триггерах?

Елена М
Дата: 24.04.2003 18:40:42
Моя большая и по-видимому не разрешимая проблема в следующем:
есть родительская таблица, на которой проводиться логическое удаление, то есть есть поле dateofarchive котрое апдейтиться ненудевым значением, в случае если запись "удалена", у родительской таблицы есть много дочерних, на которых тоже надо обновить поле dateofarchive у соответствующих дочерних записей, ну чтобы ссылочная целостность сохранилась.
проблема в том что у некоторых дочерних таблиц существуют свои тригера на BEFORE UPDATE котррый поддерживают некоторые бизнес-правила, например нельзя удалить (в нашем случае проапдейтить поле dateofarchive), если дочерняя запись последняя. И вот этот самый триггер конфликтует с родительским триггером, который пытается проапдейтить также все дочерние записи. Мы определили два пути чтобы побороть эту проблему
1) Как-то определить когда дочерний триггер вызван UPDATE выражением в родительском и тогда в процедуре триггера разрешать удаление дочерней записи
Вопрос: как определить что дочерний триггер вызван из родительского? параметры в триггеры не передаются :( Enable/disable тригеру делать в нашем случае нельзя

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

Если у кого-то будут какие-либо идеи, пожалуйста, пишите.
Niemi
Дата: 26.04.2003 22:16:57
Хмык, похоже никто не сталкивался, пиши в рассылку PGSQL , там ребята толковые, помогут, но к сожалению только не английском, хотя пару "бизонов" там есть из России и Прибалтики.