|
|
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Есть базовая таблица. Эту базовую таблицу наследуют таблицы "наследники". Написал триггер(Insert) для базовой таблицы. При вставке в одной из таблиц наследников - триггер в базовой таблице не срабатывает. Есть ли возможность заставить триггер заработать (ну или другое решение)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 20:20 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
PankonЕсть базовая таблица. Эту базовую таблицу наследуют таблицы "наследники". Написал триггер(Insert) для базовой таблицы. При вставке в одной из таблиц наследников - триггер в базовой таблице не срабатывает. Есть ли возможность заставить триггер заработать (ну или другое решение)? Самый простой вариант - вешать триггер на каждую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2008, 08:00 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Добрый день. Перевожу проект с PostgreSQL версии 7.4 на версию 9.2. В БД используется наследование. Несколько таблиц наследуют родительскую, все лежат в разных схемах БД. На каждую таблицу созданы триггеры. Возникает интересная ситуация при удалении записи из родительской таблицы под разными версиями: версия 7.4 - всё корректно работает. версия 9.2 - отмена удаления записи, из-за ошибки выполнения функции по триггеру дочерней таблицы. Оказывается, разработчик БД предусмотрел проверку в функции триггера дочерней таблицы - если запись из родительской еще не удалена, то говорим что не можем удалить запись из дочерней таблицы. Возникает несколько вопросов: 1) Как изменилась последовательность выполнения триггеров в таблицах, участвующих в наследовании? Как работало раньше и что изменилось? 2) Может идет параллельное выполнение триггерных функций? и как добиться старого поведения БД? 3) Может дело при работе в сессии и разными схемами, или выполнение транзакций? 4) Можно ли настроить сервер БД и на какие параметры нужно смотреть чтобы выяснить режим работы с транзакциями, триггерами?? Заметьте, пользователь БД пытается удалить только запись из родительской таблицы. Остальное делает сама БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 11:17 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Valentine_vaia, "ты не мудри, ты пальцем покажи" ((с)норот) скорее всего никак не изменилось и что значит "только из родительской" -- вы там так и пишете: Код: sql 1. или себе что--то навоображали ? вот и гадай тут, с запотевшим шаром ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 11:31 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Valentine_vaiaВ БД используется наследование. -1 imho ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 11:59 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
qwwq, извините, сама понимаю что трудно понять. Привожу пример: 4 схемы: sh0, sh1, sh2, sh3 В каждой есть таблица, участвующая в наследовании: tab0 - родительская, tab1, tab2, tab3 - дочерние от tab0 В таблице sh3.tab3 хранится данные по объекту, например: Код: sql 1. 2. 3. 4. 5. 6. Есть 2 триггерные функции после удаления записи из таблицы: tab0_adr9() и tab3_adr9() Для каждой из таблиц создаются триггеры: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Пытаемся удалить объект из БД: удаляем запись из tab0 с id = 1 , например, должны удалится связанные записи в дочерних таблицах. Вот код самих триггерных функций: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. Под PostgreSQL 7.4 все корректно отрабатывает. Под PostgreSQL 9.2 откатывает удаление из-за EXCEPTION: EXIST rec.id = OLD.id = 1 Из-за чего это происходит? Почему в версии 9.2 он видит уже якобы удаленный объект из sh0.tab0? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 17:40 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Valentine_vaia, покажите код, которым вызываете удаление . авторудаляем запись из tab0 с id = 1, покажите код , который вызывает (возможно каскадом) удаление из tab3 не показывайте не schema--квалифаед кода. это дурной тон дурных отцов--основателей. и с чего вы взяли, что что--то удаляет из дочерних ? у вас что, одни и те же данные разнесены во все дочерние и основную ? и есть большое сомнение, что вызов в after DELETE триггере строчки RETURN NEW; не уронит вам всё нахер гораздо раньше, чем произойдёт что--то ещё. Т.е. я не уверен, что вы показываете нужные куски кода (схему показывайте всегда). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 18:48 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
qwwq, Код: sql 1. Может я неправильно понимаю. Если удаляется запись из родительской таблицы, разве не удаляются данные по этой записи у дочерних таблиц? БД разрабатывала не я. И сама обратила внимание на метку INHERITS при создании таблиц только когда не понимала "куда деваются записи из других таблиц?" (sh1.tab1, sh2.tab2, sh3.tab3), если удаляем только из sh0.tab0.. (когда это работает в PostgreSQL v7.4) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 09:51 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
qwwq у вас что, одни и те же данные разнесены во все дочерние и основную ? Детально не изучала, слишком много таблиц и данных. Но вроде везде в дочерних id записи присутствует( можете дать ссылку на материалы по наследованию? поверхностно я уже изучила из документации и других статей. Мне интересен механизм взаимодействия родительской и дочерних таблиц при добавлении записи, удалении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 09:58 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Valentine_vaiaqwwq, Код: sql 1. Может я неправильно понимаю. Если удаляется запись из родительской таблицы, разве не удаляются данные по этой записи у дочерних таблиц? вы неправильно понимаетею то, что написано, означает "удалить все записи из [всей] иерархии sh0.tab0. а "удалить записи из родительской таблицы" пишется так: Код: sql 1. Valentine_vaiaБД разрабатывала не я. И сама обратила внимание на метку INHERITS при создании таблиц только когда не понимала "куда деваются записи из других таблиц?" (sh1.tab1, sh2.tab2, sh3.tab3), если удаляем только из sh0.tab0.. (когда это работает в PostgreSQL v7.4) просто совсем не обязательно записи с одинаковым id присутствуют во всех (или хотя бы ещё 1--й) таблицах иерархии. вообще--то говоря, судя по назначению таблицы таб3 -- заданный ид должен принадлежать конкретной какой--то одной таблице иерархии. т.е. ид должен видимо лежать в одной и только одной таблице. могу врать -- отсюда всего не видно. У вас вполне может быть ошибка данных -- что-то в 9.2. вставили против заложенной разработчиком логики, без поддержки (в обход) логической целостности -- и теперь бьётесь с логикой, которой не соответствуют вставленные данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 10:33 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Valentine_vaiaqwwq у вас что, одни и те же данные разнесены во все дочерние и основную ? Детально не изучала, слишком много таблиц и данных. Но вроде везде в дочерних id записи присутствует( можете дать ссылку на материалы по наследованию? поверхностно я уже изучила из документации и других статей. Мне интересен механизм взаимодействия родительской и дочерних таблиц при добавлении записи, удалении.ищите в приложении или БД логику, которой вставляете и апдейтите записи иерархии -- авось прояснеет устройство встроенной логики БД. или приводите полностью определенный код со схемами, а не огрызки пждампа (порождения моральных уродов--печально известных как "отцы--основатели") , где задание схемы (set search path)) отделено от описания объектов пространственно, а вы всю последовательность и не приводите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 10:41 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
qwwq, в общем, я не права. Построила наглядную схему наследования, убедилась что tab3 не участвует в наследовании. Оказывается, удаление записи происходит по правилу Код: sql 1. 2. 3. переформулирую изначальный вопрос: Почему в старой версии все данные удалялись, а в новой нет? Есть ли разница между последовательностью выполнения удаления записи из sh0.tab0 и выполнения правила по удалению следом записи из sh3.tab3? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 12:18 |
|
||
|
Триггеры и наследование
|
|||
|---|---|---|---|
|
#18+
Valentine_vaia, http://www.postgresql.org/docs/9.2/static/sql-createrule.html авторIf neither ALSO nor INSTEAD is specified, ALSO is the default. судя по всему -- проблема в очередности этого ALSO . скажем в 7. сначала удалялось из самой, а потом отрабатывало rule , а в вашем случае триггер на срабатывание rule отрабатывает раньше чем само удаление. 9.2 The transformation happens before the execution of the commands starts. хотя для 7.2 это ,якобы, в случае апдейта/делета, было так же: 7.2 otherwise it is done after the original query in the case of ON INSERT, or before the original query in the case of ON UPDATE or ON DELETE. сделайте для пробы вместо rule -- after delete триггер. (неудобство -- надо вешать триггер на каждую таблицу иерархии, в отличии от руле, которое скорее вешается на команду, чем на событие записи). тогда гарантировано очистка таб3 будет генерироваться after события delete из основной. И видится эти записи в таблицах уже, в момент проверки, не будут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 12:50 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=35545697&tid=1997363]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
159ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 496ms |

| 0 / 0 |
