Używasz transakcji autonomicznej, aby obejść fakt, że wyzwalacz nie może sam wysłać zapytania do swojej tabeli. Natrafiłeś na niesławny błąd tabeli mutacji i odkryłeś, że zadeklarowanie wyzwalacza jako autonomicznej transakcji powoduje, że błąd znika.
Nie masz jednak szczęścia, to wcale nie rozwiązuje problemu:
- Po pierwsze, tracona jest logika transakcji. Nie możesz cofnąć zmian w
suscription_facttabeli, są zaangażowani , podczas gdy Twoja główna transakcja nie jest i może zostać wycofana. Więc straciłeś również integralność danych. - Wyzwalacz nie widzi nowego wiersza, ponieważ nowy wiersz nie został jeszcze zatwierdzony! Ponieważ wyzwalacz działa w niezależnej transakcji, nie może zobaczyć niezatwierdzonych zmian wprowadzonych przez główną transakcję:otrzymasz całkowicie błędne wyniki.
Dlatego nigdy nie powinieneś robić żadnej logiki biznesowej w transakcjach autonomicznych. (istnieją legalne aplikacje, ale są one prawie całkowicie ograniczone do logowania/debugowania).
W Twoim przypadku powinieneś:
- Zaktualizuj swoją logikę, aby nie musiała wykonywać zapytań do tabeli (aktualizacja
suscription_facttylko jeśli nowy wiersz jest nowszy niż stara wartość przechowywana wid_date_unsuscription). - Zapomnij o używaniu logiki biznesowej w wyzwalaczach i użyj procedury, która poprawnie aktualizuje wszystkie tabele lub użyj widoku, ponieważ tutaj mamy wyraźny przypadek nadmiarowych danych.
- Użyj obejścia, które faktycznie działa (przez Toma Kyte) .
Zdecydowanie radziłbym używać tutaj (2). Nie używaj wyzwalaczy do kodowania logiki biznesowej. Trudno je pisać bez błędów, a jeszcze trudniej utrzymać. Korzystanie z procedury gwarantuje, że cały odpowiedni kod jest zgrupowany w jednym miejscu (pakiet lub procedura), łatwy do odczytania i przestrzegania oraz bez nieprzewidzianych konsekwencji.
