Zagnieżdżanie wyzwalaczy

Zagnieżdżanie wyzwalaczy ma ograniczoną głębokość, chroniącą przed nieskończoną pętlą wzajemnych wywołań.

Na czym polega zagnieżdżanie wyzwalaczy

Zagnieżdżanie wyzwalaczy występuje wtedy, gdy wykonanie jednego wyzwalacza powoduje operację na danych, która uruchamia kolejny wyzwalacz. Przykładowo wyzwalacz związany z dodaniem rekordu do tabeli może automatycznie zmienić dane w drugiej tabeli, a ta zmiana może uruchomić następny wyzwalacz. Łańcuch takich zależności może obejmować kilka tabel i różne rodzaje operacji, takie jak INSERT, UPDATE oraz DELETE.

Wyzwalacz nie jest zwykłą funkcją wywoływaną bezpośrednio przez aplikację. Jego uruchomienie wynika z wystąpienia określonego zdarzenia zdefiniowanego w silniku bazy danych. Zależnie od konkretnego systemu wyzwalacz może działać przed operacją, po niej albo zamiast niej. Jeżeli kod wyzwalacza wykonuje kolejną operację objętą regułą innego wyzwalacza, powstaje zagnieżdżenie. Dokładne zasady uruchamiania, kolejność wykonywania i możliwość wyłączania zagnieżdżeń są zależne od użytego silnika bazy danych.

Dlaczego silnik ogranicza głębokość wywołań

Ograniczenie głębokości zagnieżdżania chroni bazę danych przed nieskończonym cyklem. Taki cykl może powstać na przykład wtedy, gdy wyzwalacz A modyfikuje tabelę obsługiwaną przez wyzwalacz B, a wyzwalacz B ponownie modyfikuje dane uruchamiające wyzwalacz A. Bez mechanizmu ochronnego operacja mogłaby powtarzać się aż do wyczerpania stosu wywołań, pamięci lub czasu przeznaczonego na wykonanie transakcji.

Przekroczenie dopuszczalnego poziomu zagnieżdżenia jest zwykle traktowane jako błąd wykonania i powoduje przerwanie bieżącej operacji. Jeżeli wyzwalacze działają w ramach jednej transakcji, skutki zależnych zmian mogą zostać wycofane razem z operacją, choć szczegółowe zachowanie zależy od silnika oraz sposobu obsługi błędów. Sam limit nie naprawia błędnej logiki. Jedynie ogranicza jej skutki i pozwala systemowi zakończyć niekontrolowany łańcuch zamiast kontynuować go bez końca.

Śledzenie łańcucha zależności w bazie

Diagnozę należy rozpocząć od ustalenia, jakie zdarzenie uruchomiło pierwszy wyzwalacz oraz jakie instrukcje modyfikujące dane wykonuje jego kod. Następnie trzeba sprawdzić, czy modyfikowane tabele mają własne wyzwalacze i czy ich działania prowadzą do kolejnych zmian. Przydatny jest schemat zależności przedstawiający kierunek przepływu: operacja aplikacji, pierwszy wyzwalacz, tabela pośrednia, następny wyzwalacz i ewentualny powrót do obiektu początkowego.

W praktyce warto rozdzielić wyzwalacze uruchamiane bezpośrednio przez operację od tych uruchamianych pośrednio przez kod innych wyzwalaczy. Należy też sprawdzić, czy wyzwalacz przetwarza pojedynczy rekord, czy cały zbiór rekordów objętych instrukcją. Błędne założenie, że wyzwalacz wykona się tylko raz dla jednego wiersza, może prowadzić do nadmiarowych aktualizacji i trudnych do wykrycia efektów ubocznych. Logi silnika, komunikaty transakcyjne oraz ślad wykonywanych instrukcji pomagają ustalić, który wyzwalacz doprowadził do przekroczenia limitu.

Bezpieczne projektowanie reakcji na zmiany danych

Wyzwalacz powinien wykonywać możliwie wąski, jasno określony zakres pracy. W kodzie należy unikać modyfikowania tabel, które pośrednio prowadzą do ponownego uruchomienia tej samej ścieżki, chyba że taki efekt jest zamierzony i kontrolowany. Ochronę przed rekurencją można projektować przez warunek sprawdzający, czy zmiana rzeczywiście wymaga dalszej reakcji, przez rozdzielenie tabel źródłowych i wynikowych albo przez zastosowanie mechanizmu dostępnego w konkretnym silniku do kontroli zagnieżdżonych wyzwalaczy.

Przed wdrożeniem zmian trzeba przetestować operacje pojedyncze i zbiorcze, w tym dodawanie, modyfikowanie oraz usuwanie danych. Test powinien potwierdzić oczekiwaną liczbę uruchomień, kolejność zależności, zachowanie w przypadku błędu i wynik całej transakcji. Jeżeli limit zagnieżdżenia zostaje osiągnięty podczas pozornie prostej operacji, wskazuje to na zbyt silne sprzężenie reguł albo brak warunku kończącego. W takiej sytuacji naprawa polega na przeanalizowaniu przepływu danych i usunięciu cyklu, a nie na mechanicznym zwiększaniu limitu.