Ja oceniam liquibase dla projektu rozpoczynającego się dzisiaj.Kilka pytań od truibase noob
Ktoś użył go do tworzenia procedur, funkcji, w zasadzie wszystkie rzeczy plsql?
Jeśli nie, czy można zapisać osadzony kod SQL w plikach xml?
Z góry dziękuję.
W instrukcji obsługi znajduje się wbudowany znacznik createProcedure do zarządzania procedurami. Najlepszym podejściem jest zwykle łączenie tagów z runOnChange, więc płynna aktualizacja zaktualizuje twoją procedurę tylko wtedy, gdy zaktualizujesz definicję. W ten sposób możesz z czasem różnicować pliki dzienników zmian w pliku changelog i sprawdzać, jak zmieniła się procedura.
Używanie znacznika sqlFile do pliku referencyjnego na przechowywany proces jest również popularne, lub, jak powiedziałeś, możesz użyć znacznika sql do wstawienia niestandardowego sql.
Podczas gdy nie używałem Lasera do procedur przechowywanych, mam pewne doświadczenie z Liquibase dla bardziej ogólnych operacji.
Możliwe jest pisanie niestandardowego sql, osadzonego w pliku xml lub przywołanego z zewnętrznego pliku.
Napotkano problemy przy próbie użycia znacznika sql do procedur składowanych, wyzwalaczy i funkcji, ale w moim przypadku były to udane problemy ze sterownikiem JDBC MySQL, a nie samo Liquibase. Praktyka, w której się znalazłem, polega na użyciu refaktoryzacji sqlFile, jak sugeruje Nathan, a następnie na kontrolowaniu kodu SP/trigera/funkcji w tym samym projekcie, co dziennik zmian, wersjonowany w systemie kodu źródłowego wraz z nim. Pozwala to zarządzać SP/dowolnym kodem, tak jak był to prawdziwy kod źródłowy.
Ustawienie parametru runOnChange = "true" w zestawie zmian zawierającym refaktoryzację sqlFile jest niezbędne. Jest to przełącznik (dziękuję, Nathan), który umożliwia rzeczywistą kontrolę źródła kodu proceduralnej bazy danych.
Hej Tim, więc jeśli zrozumiem sedno tego, czy logiczne byłoby mieć plik {schemaName}/sprocs/populated with sproc_name.xml, a następnie Liquibase wykrywa i aktualizuje schemat, gdy pliki te są aktualizowane? – David
To by działało, ale myślę, że byłoby to trochę nieporęczne. To, co zrobiłem, ma jeden dziennik zmian "stored-proc.xml" (lub coś takiego), który zawiera zmiany "runOnChange =" true ", z których każdy uruchamia pojedynczy idempotent, skrypt SQL tworzący SP, zlokalizowany w bazie danych db/src /procs/*.sql (lub gdzieś). Tak długo, jak aktualizujesz tę listę zmian za każdym razem, gdy kod SP może się zmienić, zawsze będziesz mieć aktualne bazy danych w bazie danych i kontroli źródła. Po dodaniu nowego SP dodaj nowy zestaw zmian do tego dziennika zmian. Działa świetnie! – tlberglund
WOW !!! Tak się cieszę, że Cię tu znasz :) – Tom
Jestem wszędzie :) LMK, jeśli napotkasz jakiekolwiek inne pytania lub problemy, lub potrzebujesz więcej wyjaśnień –