W pracy mamy tabelę do przechowywania ustawień, które zasadniczo zawiera następujące kolumny:Prevent aktualizacja do nieistniejących wierszy
PARAMNAME
VALUE
Większość czasu nowych ustawień dodane, ale w rzadkich przypadkach ustawienia są usuwane. Niestety oznacza to, że wszelkie skrypty, które mogły wcześniej zaktualizować tę wartość, będą nadal działać pomimo tego, że aktualizacja zakończy się wynikiem "0 rows updated
" i prowadzi do nieoczekiwanego zachowania.
Ta sytuacja została ostatnio zauważona przez niepowodzenie testu regresyjnego, ale dopiero po wielu badaniach, dlaczego dane w systemie były inne.
Moje pytanie brzmi: Czy istnieje sposób generowania warunku błędu, gdy aktualizacja powoduje zaktualizowanie zerowych wierszy?
Oto kilka opcji myślałem o, ale żaden z nich są naprawdę wszystko, co pożądane:
- PL/SQL wrapper który zauważa uszkodzony aktualizację i zgłasza wyjątek.
- Nie jest idealny, ponieważ nie zatrzymuje nikogo/skryptu przed ręcznym robieniem aktualizacji.
- Wyzwalacz na stole, który zgłasza wyjątek.
- Wynika z naszej obecnej polityki wycofywania wyzwalaczy.
- Wymaga aktualizacji wyzwalacza za każdym razem, gdy usuwane jest ustawienie i utrzymywania listy przestarzałych ustawień (w przypadku wykluczenia).
- Może mieć problemy z tabelą mutowania (jeśli włączasz, sprawdzając, jakie ustawienia istnieją).
Jak uaktualnienie 0 wierszy doprowadzić do sygnalizowania czy dane są różne? –
@TheNail Ustawienie dotyczyło opóźnienia. W starym kodzie wartość została zaktualizowana, a dane zawierały dane opóźnienie. W nowym kodzie nie było. Regresja Ergo. Dokładnie to samo by się stało, gdyby ustawienie kontrolowało, czy jakaś funkcja była włączona, czy nie. –