Operacja modyfikująca setki rekordów może być zgodna z przyjętymi regułami, a mimo to objąć więcej danych, niż oczekiwano. Ogólne potwierdzenie — „Czy na pewno?” — nie pozwala ocenić zakresu ani wykryć nieoczekiwanych warunków. Podgląd zmian w PHP powinien pokazywać, których rekordów dotyczyłaby operacja, jakie wartości uległyby zmianie i w jakich warunkach można ją wykonać.
Podgląd ogranicza ryzyko niespodzianek, ale nie gwarantuje, że późniejsze wykonanie przyniesie dokładnie taki sam wynik. Pomiędzy tymi etapami mogą zmienić się dane, uprawnienia lub zakres operacji. Projekt powinien ujawniać tę niepewność i ponownie weryfikować wszystko, co niezbędne, przed zapisem.
Kiedy podgląd jest przydatny
Warto rozważyć podgląd w przypadku operacji masowych, wrażliwych lub trudnych do odwrócenia: aktualizacji cen, zmiany statusów, ponownego przypisywania kont, usuwania informacji lub przeliczania danych pochodnych. Przydaje się również wtedy, gdy osoba inicjująca zadanie musi ocenić jego wpływ lub uzyskać zgodę przed wykonaniem.
Nie każda akcja wymaga interfejsu podglądu. Jeśli operacja jest niewielka, odwracalna i daje jednoznaczny rezultat, może wystarczyć kontekstowe potwierdzenie. Jeśli jednak użytkownik nie potrafi ocenić, co oznacza potwierdzenie, problem wymaga pokazania konkretnych danych, a nie dodania kolejnego okna dialogowego.
Podgląd nie zastępuje też kopii zapasowej, mechanizmu wycofania ani polityki zatwierdzania. Jeśli błąd może mieć poważne konsekwencje, należy rozważyć dodatkowe zabezpieczenia, takie jak zatwierdzenie przez inną osobę, stopniowe wykonanie lub sprawdzony proces odzyskiwania.
Oddzielenie obliczania od zastosowania zmian
Reguła biznesowa powinna umożliwiać obliczenie propozycji bez modyfikowania bazy danych. Praktycznym rozwiązaniem jest współdzielenie logiki wyboru i obliczeń przez dwa tryby: jeden opisuje zmiany, a drugi je stosuje. Unikanie dwóch niezależnych implementacji zmniejsza ryzyko, że podgląd i wykonanie będą interpretować reguły w różny sposób.
Propozycja może zawierać dla każdego elementu, którego dotyczy:
- Identyfikator pozwalający rozpoznać rekord.
- Istotne wartości bieżące i wartości oczekiwane.
- Powód uwzględnienia lub wykluczenia elementu.
- Przeprowadzone walidacje i wykryte konflikty.
- Zakres operacji, na przykład filtry, konto lub przedział czasu.
Na przykład operacja zmiany statusu zamówień może pokazywać obecny status, proponowany status i powód kwalifikacji. Jeśli elementów jest zbyt dużo, by wyświetlić je wszystkie, można przedstawić łączną liczbę i próbkę, zawsze jasno informując, co jest pokazywane, oraz umożliwiając w razie potrzeby sprawdzenie lub wyeksportowanie szczegółów.
W PHP warto zamknąć logikę wyboru i obliczeń w komponentach o jasno określonych odpowiedzialnościach. Usługa domenowa może generować proponowane zmiany, inny komponent może je prezentować, a warstwa aplikacyjna może odpowiadać za walidację i zapis. Podgląd nie powinien pośrednio wykonywać zapisu przez efekty uboczne odczytu.
Weryfikacja danych, uprawnień i zakresu
Przydatna propozycja wyjaśnia nie tylko, co uległoby zmianie, ale także dlaczego można tę zmianę wprowadzić. Weryfikuj warunki biznesowe na podstawie aktualnych danych i sprawdzaj, czy użytkownik ma uprawnienia do przeglądania oraz wykonania operacji. Uprawnienie do odczytu rekordów nie musi oznaczać uprawnienia do ich modyfikacji.
Zakres powinien być jasno określony. Jeśli akcja zależy od filtrów, zaznaczonego wyboru lub przesłanego pliku, zapisuj te parametry w zrozumiały sposób i informuj o limitach, wykluczeniach oraz błędach. Nie dopuść, by szerokie wyszukiwanie lub pominięty filtr przypadkowo zmieniły ograniczoną akcję w modyfikację globalną.
Należy również wskazać, czego nie da się przewidzieć z pewnością. Podgląd nie przewiduje automatycznie zmian wprowadzonych przez inne procesy, reguł wykonywanych w systemach zewnętrznych ani efektów ubocznych zależnych od przyszłego stanu. Jeśli występują integracje, kolejki lub późniejsze obliczenia, opisz te efekty oddzielnie i nie przedstawiaj ich jako potwierdzonej części wyniku.
Zapobieganie zastosowaniu nieaktualnej propozycji
Podgląd przedstawia dane z konkretnego momentu. Jeśli zmienią się przed wykonaniem, zamówienie może przestać spełniać warunki, użytkownik może utracić uprawnienia, a rekord może zostać zaktualizowany przez inny proces. Dlatego wyświetlonego wyniku nie należy traktować jako stałego upoważnienia do zapisu.
Podczas wykonywania ponownie sprawdź warunki decydujące o kwalifikacji i uprawnienia. W zależności od przypadku możesz porównać wersję rekordu, znacznik czasu lub istotne wartości z tymi, które odczytano przy obliczaniu propozycji. W razie rozbieżności nie stosuj po cichu innej decyzji: poinformuj o konflikcie i poproś o wygenerowanie nowego podglądu albo jego jawne rozstrzygnięcie.
W procesach wymagających ścisłej zgodności zachowaj odwołanie do propozycji i sprawdź, czy jej zakres oraz reguły nadal obowiązują przy stosowaniu zmian. Transakcja może zabezpieczyć zestaw zapisów przed błędami pośrednimi, ale sama nie eliminuje czasu, który upłynął między podglądem a wykonaniem. Strategia obsługi współbieżności powinna odpowiadać ryzyku i skali operacji.
Wykonywanie partiami i rejestrowanie wyników
W przypadku dużych wolumenów wykonanie całości w jednej operacji może wydłużyć czas blokad i utrudnić odzyskiwanie. Ustal limity partii odpowiednie dla bazy danych i działania aplikacji. W przypadku częściowych błędów użytkownik powinien móc odróżnić rekordy zmodyfikowane, pominięte i wymagające sprawdzenia.
Rejestruj wystarczająco dużo informacji, by móc zbadać wynik: kto zainicjował i zatwierdził operację, kiedy ją przygotowano i wykonano, jaki zakres wskazano, ile elementów przetworzono i jakie wystąpiły błędy. Nie zapisuj bez potrzeby danych osobowych ani wrażliwych wartości; dzienniki audytowe również muszą podlegać odpowiednim zasadom kontroli dostępu i retencji.
Jeśli operacja jest ponawiana, uwzględnij idempotencję: powtórzenie żądania nie powinno powodować nieoczekiwanych, zduplikowanych efektów. Identyfikator operacji i jej statusy mogą pomóc rozpoznawać powtórzone żądania oraz oddzielić przygotowanie, zatwierdzenie, wykonanie i zakończenie. Nie przedstawiaj wdrożenia kodu jako równoznacznego z udostępnieniem lub włączeniem operacji: to odrębne decyzje, które wymagają własnych zabezpieczeń.
Testowanie, czy podgląd nie modyfikuje danych
Testy powinny sprawdzać zarówno obliczenia, jak i brak zapisów w trybie podglądu. Korzystaj z reprezentatywnych danych, aby zweryfikować uwzględniane i wykluczane elementy, wartości bieżące i proponowane, niewystarczające uprawnienia oraz nieudane walidacje.
Sprawdź też, czy wykonanie stosuje oczekiwaną propozycję i czy zmiany współbieżne wywołują zdefiniowane zachowanie. W razie potrzeby testuj błędy wewnątrz partii, ponowienia i błędy integracji. Testy integracyjne z bazą danych są istotne: test jednostkowy obliczeń nie dowodzi, że ścieżka podglądu nie ma efektów ubocznych.
Przypadki brzegowe powinny obejmować puste filtry, duże wolumeny, rekordy usunięte lub zmienione między etapami oraz użytkowników o różnych zakresach dostępu. Warto też sprawdzić, czy interfejs nie obiecuje, że „dokładnie te elementy zostaną zaktualizowane”, jeśli podczas wykonania zestaw będzie obliczany ponownie.
Lista kontrolna ułatwiająca dobór zabezpieczeń
- Czy operacja obejmuje wiele rekordów, ma trudne do odwrócenia skutki lub wymaga zatwierdzenia?
- Czy pokazano zakres, elementy, których dotyczy operacja, oraz wartości bieżące i oczekiwane?
- Czy podgląd jest oddzielony od zapisów i ich efektów ubocznych?
- Czy uprawnienia, reguły biznesowe i dane są weryfikowane zarówno podczas przygotowania, jak i wykonania?
- Czy wykrywane są istotne zmiany, które zaszły między tymi etapami?
- Czy określono limity partii, sposób obsługi częściowych błędów i odpowiedni zakres rejestrowania zdarzeń?
- Czy testy potwierdzają, że podgląd nie modyfikuje danych, a wykonanie respektuje zweryfikowany wynik?
Podgląd jest odpowiedni, gdy pomaga podjąć świadomą decyzję, a jego ograniczenia są jasne. Jeśli nie można wiarygodnie oszacować wpływu, lepiej ograniczyć zakres, najpierw wykonać operację w kontrolowanym środowisku lub wymagać dodatkowego przeglądu, zamiast przedstawiać liczbę albo częściową listę jako obietnicę rezultatu.
