Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Порядок срабатывания триггеров. / 18 сообщений из 18, страница 1 из 1
21.06.2004, 12:56:43
    #32569469
Nikola18
Nikola18
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Есть 2 таблицы. Со второй FK на ID первой с условием on delete CASCADE.
На обоих таблицах висят триггеры на удаление, которые формируют скрипты
и сохраняют их в лог-таблице (т.е. в третьей, не связанной с этими).
Порядок записи этих скриптов весьма важен.
При реализации триггеров исходил из того, что они вызываются в порядке:
Before Delete Table1 -> Before Delete Table2 -> After Delete Table2 -> After Delete Table1
а оказалось по другому:
Before Delete Table1 -> After Delete Table1 -> Before Delete Table2 -> After Delete Table2

А как по мнению общественности должно быть, и как реализовано на других базах?
Это к вопросу о том, как планировать дальнейшую работу?

P.S.: Пользую для разработки 882-го дятла.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 13:30:12
    #32569575
Johnmen
Johnmen
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
>А как по мнению общественности должно быть

Не знаю, как там вся общественность, но от себя скажу.
Должно быть так, как есть. Т.е. ссылочная целостность реализована на системном триггере AFTER DELETE.
Но это не догма. Его можно переделать на BEFORE. Но логика, естественно, изменится, и будет, как у тебя в первом варианте....
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 14:12:38
    #32569677
Nikola18
Nikola18
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
JohnmenДолжно быть так, как есть. Т.е. ссылочная целостность реализована на системном триггере AFTER DELETE.
Но это не догма. Его можно переделать на BEFORE. Но логика, естественно, изменится, и будет, как у тебя в первом варианте....

А как я могу изменить на BEFORE?
И какова будет область влияния этих изменений (таблица, база, сервер)?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 14:19:50
    #32569699
olol
olol
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Nikola18
Порядок записи этих скриптов весьма важен.

Пока триггер After не прошел - все изменения для других еще невидны...
Например SELECT найдет эту (удаляемую) запись...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 14:44:26
    #32569790
Nikola18
Nikola18
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
olol
Пока триггер After не прошел - все изменения для других еще невидны...
Например SELECT найдет эту (удаляемую) запись...

Это не просто SELECT. Это удаление таблиц или модификация реквизитов таблиц, которая выполняется спустя какое-то время. И очень неудобно получается, когда сначала удаляется вся таблица, а уж потом её реквизиты (тут и возникает ошибка).

Провёл эксперимент на дятле:
при вхождении в BEFORE TRIGGER второй таблицы записи в первой уже ненахожу %(.

JohnmenДолжно быть так, как есть. Т.е. ссылочная целостность реализована на системном триггере AFTER DELETE.
Только что с друзьями провели эксперимент на ORACLE9
и там порядок срабатывания триггеров оказался "правильный" по сравнению с Yaffil.
Думаю что и логика подсказывает ораклейный порядок
( before Delete Table1 -> Before Delete Table2 -> After Delete Table2 -> After Delete Table1 ).

Уже очень хочу поменять порядок.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 14:48:52
    #32569802
Nikola18
Nikola18
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Может это только на Yaffil такое, а на IB или FB по другому?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 15:00:16
    #32569829
olol
olol
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Nikola18
А как я могу изменить на BEFORE?

А зачем нужно вообще менять?

Лучше сделать нормальную логику работы...

Например можно без всякого CASCADE:


SET TERM ^;
CREATE TRIGGER DropTable1 FOR Table1
ACTIVE BEFORE DELETE POSITION 0
AS BEGIN
INSERT INTO Table1D (ID1,...) VALUES (old.ID1,...);
DELETE FROM Table2 WHERE ID1 = old.ID1
END ^
SET TERM ;^

SET TERM ^;
CREATE TRIGGER DropTable2 FOR Table2
ACTIVE AFTER DELETE POSITION 0
AS BEGIN
INSERT INTO Table2D (ID1,...) VALUES (old.ID1,...);
END ^
SET TERM ;^


Nikola18
получается, когда сначала удаляется вся таблица, а уж потом её реквизиты

В примере: на BEFORE в первой таблице делаем ее копию...
на AFTER во второй - копии связанных к полученной первой...

Вроде должно все работать...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 15:09:55
    #32569856
Nikola18
Nikola18
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
olol
В примере: на BEFORE в первой таблице делаем ее копию...
на AFTER во второй - копии связанных к полученной первой...

Вроде должно все работать...
Дык это уже проверено и всё работает, так и приходится ручками прописывать строки удаления.
Но случайно можно и забыть где какие таблицы находятся в CASCADE связи, а прверять всё просто лень. Да и для чего тогда СУБД?

Вопрос, наверно, просто в принципе как должно быть.
И если в FB1.5 сделано правильно переберусь туда, благо платформы совместимые.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 15:20:25
    #32569875
olol
olol
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
автор

Мой пример копирует удаляемые записи из таблиц в буферные.

Если говорить о порядке записи в скриптах, то если запись делать на AFTER в обоих таблицах, - то сначала будут связанные записи а потом основная...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 16:25:07
    #32570068
olol
olol
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
автор

Прошу прощения на CASCADE действительно будет так поскольку все CONSTRAINT обрабатываются по окончанию действия (оно и правильно наверно).

Проверил на IB6...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 16:25:49
    #32570071
Johnmen
Johnmen
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Nikola18
Только что с друзьями провели эксперимент на ORACLE9
и там порядок срабатывания триггеров оказался "правильный" по сравнению с Yaffil.
Думаю что и логика подсказывает ораклейный порядок


Дело в том, что "правильны" оба варианта. И когда системный триггер удаляет из детальной таблицы по AFTER DELETE основной, и по BEFORE DELETE основной.
Разработчики IB и клонов выбрали AFTER.
И я думаю, что это "правильней", т.к. в детальной табл. можно удалять только после удаления в основной. Такой порядок более "устойчив" для обеспечения целостности.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 17:00:06
    #32570160
Nikola18
Nikola18
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
JohnmenИ я думаю, что это "правильней", т.к. в детальной табл. можно удалять только после удаления в основной. Такой порядок более "устойчив" для обеспечения целостности.
Позволю с Вами не согласиться. Вот как раз для большей "устойчивости" в обеспечении целостности удаление PK должно производиться только после удаления всех ссылок на него.

Кроме всего прочего существует ещё один аспект:
я полагаю, что запись, генерирующая каскадные изменения в базе должна иметь возможность анализировать результат этого каскада, а для этого она должна получить управление после обхода всех FKeys. А при действующей у IB и его клана метадологии это получить нельзя, т.к. триггер PK AFTER XXXXXXXX сработает в начале и всё.
Не думаю, что разработчики IB/FB/Yaffil этого не понимали, поэтому надеюсь, что это либо просто глюк, либо недоработка. Но если это сознательный выбор, то очень хочется чтоб этот выбор был расширен до возможности выбирать пользователем принцип каскадных обновлений/удалений.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 17:15:38
    #32570210
Johnmen
Johnmen
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Nikola18
Позволю с Вами не согласиться. Вот как раз для большей "устойчивости" в обеспечении целостности удаление PK должно производиться только после удаления всех ссылок на него.


Пожалуйста. Не соглашайся.
Всё ведь сводится к тому, что хуже. Битые ссылки или потерянные ссылки...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 20:23:57
    #32570509
hvlad
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Nikola18 JohnmenИ я думаю, что это "правильней", т.к. в детальной табл. можно удалять только после удаления в основной. Такой порядок более "устойчив" для обеспечения целостности.
Позволю с Вами не согласиться. Вот как раз для большей "устойчивости" в обеспечении целостности удаление PK должно производиться только после удаления всех ссылок на него.

Кроме всего прочего существует ещё один аспект:
я полагаю, что запись, генерирующая каскадные изменения в базе должна иметь возможность анализировать результат этого каскада, а для этого она должна получить управление после обхода всех FKeys. А при действующей у IB и его клана метадологии это получить нельзя, т.к. триггер PK AFTER XXXXXXXX сработает в начале и всё.
Не думаю, что разработчики IB/FB/Yaffil этого не понимали, поэтому надеюсь, что это либо просто глюк, либо недоработка. Но если это сознательный выбор, то очень хочется чтоб этот выбор был расширен до возможности выбирать пользователем принцип каскадных обновлений/удалений.

Удаляем мастера. Системный триггер срабатывает перед реальным удалением мастера. Детали удалены. Параллельно вставляем новую деталь с сылкой на удаляемого мастера. Что получим ? Правильно - деталь без мастера. А если мастера удалим сначала , то новую деталь уже не вставить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.06.2004, 22:29:16
    #32570580
Злобастый
Злобастый
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Здорово, Влад!
Зашел развлечься? ;)
Тут всегда весело...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.06.2004, 05:33:49
    #32570668
olol
olol
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
Nikola18
...приходится ручками прописывать строки удаления.
Но случайно можно и забыть где какие таблицы находятся в CASCADE связи, а проверять всё просто лень. Да и для чего тогда СУБД?


Я что-то непойму в чем разница: одна строка DELETE или одна строка с CONSTRAINT.

Как можно забыть написать одну и не забыть написать другую.
Тем более что и порядок получится тогда "правильный".
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.06.2004, 10:02:53
    #32570895
hvlad
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
ЗлобастыйЗдорово, Влад!
Привет

ЗлобастыйЗашел развлечься? ;)
Тут всегда весело...
Да уж ;)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.06.2004, 10:10:05
    #32570915
fedd
fedd
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Порядок срабатывания триггеров.
hvlad ЗлобастыйЗдорово, Влад!
Привет

ЗлобастыйЗашел развлечься? ;)
Тут всегда весело...
Да уж ;)

смеетесь над нами, крутые? ;)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Порядок срабатывания триггеров. / 18 сообщений из 18, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 437ms
Закрыть
start [/forum/topic.php?fid=40&mobile=1&tid=1578399]:
 0ms
get settings:
 7ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 153ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 50ms
get tp. blocked users:
 1ms
others: 194ms
total:  437ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]