Modyfikacja funkcji

Modyfikacja funkcji to zmiana jej definicji poleceniem ALTER FUNCTION, z zachowaniem nadanych wcześniej uprawnień.

Na czym polega modyfikacja funkcji w bazie danych

Modyfikacja funkcji polega na zmianie właściwości albo definicji istniejącego obiektu programowalnego w bazie danych. Funkcja jest zapisanym fragmentem logiki, który przyjmuje określone argumenty i zwraca wynik. Może wykonywać obliczenia, przekształcać wartości, odczytywać dane z tabel albo realizować część powtarzalnego procesu wykonywanego przez aplikację. Zmiana takiej funkcji wpływa więc nie tylko na sam kod zapisany w bazie, lecz także na wszystkie zapytania, procedury i moduły aplikacji, które ją wywołują.

W środowisku obsługującym polecenie ALTER FUNCTION modyfikacja może dotyczyć między innymi nazwy funkcji, jej parametrów, typu zwracanego wyniku, właściciela, schematu, właściwości wykonania lub sposobu interpretowania zależności. Zakres dostępnych zmian zależy od konkretnego silnika bazy danych. Nie każdą cechę można zmienić bezpośrednio. Jeżeli zmiana obejmuje sygnaturę funkcji, czyli zestaw jej parametrów i ich typów, często konieczne jest usunięcie istniejącego obiektu oraz utworzenie nowego albo zastosowanie mechanizmu właściwego dla danego silnika.

Definicja, sygnatura i wynik zwracany przez funkcję

Przed modyfikacją należy ustalić, która funkcja ma zostać zmieniona. W bazie danych może istnieć kilka funkcji o tej samej nazwie, lecz różnych typach argumentów. Taki mechanizm nazywa się przeciążaniem funkcji. Sam zapis nazwy może zatem nie wystarczyć do jednoznacznego wskazania obiektu. Istotne są również schemat, kolejność parametrów oraz ich typy. Pomylenie funkcji może spowodować zmianę logiki używanej przez inną część systemu.

Zmiana ciała funkcji, czyli instrukcji wykonywanych po jej wywołaniu, może zmienić sposób obliczania wyniku, filtrowania rekordów lub obsługi wartości pustych. Szczególne znaczenie ma zgodność typu zwracanego wyniku z oczekiwaniami kodu wywołującego. Funkcja zwracająca pojedynczą wartość nie jest używana w taki sam sposób jak funkcja zwracająca zbiór rekordów. Również zmiana kolejności kolumn w wyniku tabelarycznym może doprowadzić do błędnej interpretacji danych, nawet jeśli same zapytania nadal przechodzą analizę składniową.

W praktyce warto porównać poprzednią i nową definicję funkcji oraz sprawdzić wszystkie miejsca jej użycia. Należy zweryfikować liczbę argumentów, ich typy, wartości domyślne, typ wyniku i zachowanie dla danych granicznych. Test powinien obejmować zarówno poprawne dane wejściowe, jak i przypadki takie jak wartość NULL, pusty zbiór, brak powiązanego rekordu lub powtarzające się wartości. Dopiero wtedy można ocenić, czy modyfikacja zmienia wyłącznie zamierzoną część działania.

Uprawnienia, właściciel i zależności obiektu

Zmiana funkcji nie powinna automatycznie oznaczać utraty wcześniej nadanych uprawnień do jej wykonywania. Uprawnienia są jednak zarządzane przez konkretny silnik bazy danych i zależą od rodzaju wykonywanej operacji. Modyfikacja istniejącego obiektu może zachować jego tożsamość oraz przypisane prawa, natomiast usunięcie funkcji i utworzenie nowej może spowodować konieczność ponownego nadania uprawnień. Z tego powodu nie należy zastępować polecenia modyfikującego operacją usunięcia bez sprawdzenia skutków dla użytkowników i ról.

Znaczenie ma również właściciel funkcji oraz uprawnienia osoby wykonującej zmianę. W wielu systemach tylko właściciel obiektu albo użytkownik posiadający odpowiednie uprawnienia administracyjne może zmienić jego definicję. Funkcja może także działać z prawami wywołującego albo z prawami właściciela, zależnie od konfiguracji i mechanizmów dostępnych w danym silniku. Zmiana właściwości bezpieczeństwa może rozszerzyć lub ograniczyć dostęp do danych, dlatego powinna być traktowana jako zmiana zachowania, a nie wyłącznie korekta techniczna.

Funkcja może być powiązana z widokami, innymi funkcjami, procedurami, wyzwalaczami lub kodem aplikacji. Czasem silnik potrafi wykryć zależności podczas zmiany, ale nie wszystkie zależności muszą być widoczne w prostym poleceniu modyfikującym. Należy uwzględnić również odwołania zapisane w skryptach, zadaniach automatycznych i konfiguracji aplikacji. Szczególnie ryzykowna jest zmiana typu wyniku albo znaczenia parametrów przy zachowaniu tej samej nazwy, ponieważ wywołania mogą nadal działać składniowo, lecz zwracać inne dane.

Bezpieczne sprawdzenie zmiany funkcji

Bezpieczna modyfikacja powinna rozpocząć się od odczytania aktualnej definicji funkcji, jej schematu, właściciela, parametrów i uprawnień. Następnie należy przygotować zmianę w sposób możliwy do odtworzenia, na przykład jako wersjonowany skrypt zawierający polecenie ALTER FUNCTION albo odpowiednią definicję funkcji dla używanego silnika. Skrypt powinien jednoznacznie wskazywać obiekt, a jego wykonanie powinno być poprzedzone sprawdzeniem, czy środowisko docelowe zawiera oczekiwaną wersję funkcji.

Po wykonaniu modyfikacji należy ponownie odczytać definicję i porównać ją z planowaną wersją. Trzeba także sprawdzić, czy zachowały się uprawnienia ról korzystających z funkcji oraz czy funkcja jest dostępna pod właściwą nazwą i w odpowiednim schemacie. Testy powinny uruchamiać funkcję z reprezentatywnymi argumentami, sprawdzać typ i zawartość wyniku oraz obejmować błędy przewidziane dla nieprawidłowych danych. Jeżeli funkcja odczytuje lub zmienia dane, test należy wykonać na kontrolowanym zbiorze, aby nie doprowadzić do niezamierzonych zmian.

W przypadku problemu trzeba ustalić, czy błąd wynika z samej definicji, niezgodności sygnatury, braku uprawnień, zależności od innego obiektu, różnicy wersji silnika czy odmiennej konfiguracji sesji. Sam fakt pomyślnego wykonania polecenia nie potwierdza poprawności działania funkcji. O poprawnej modyfikacji można mówić dopiero wtedy, gdy definicja, uprawnienia, zależności i wyniki wywołań są zgodne z wymaganym zachowaniem systemu.