Rozważmy typowego CRUDa.
Do tej pory generowałem DDL jakimś zewnętrznym softem. Później to DDL było z ręki odpalane bezpośrednio na bazie, ewentualnie np. flywayem.
Czy da się to lepiej robić? Szczególnie chodzi mi o nowe crudy.
Słyszałem, że jest opcja żeby to spring wygenerował DDL, albo że jest opcja żeby te bazy się same stawiały bez żadnego odpalania DDL.
Ogólnie jak wyglądają tutaj najlepsze praktyki?
Każdy przyzwoity ORM ma opcje generowania schematu bazy danych (np. Hibernate). Ale jest to pojmowane jako bardzo zła praktyka. Większość komercyjnych projektów korzystała albo z Liquibase'a albo z Flyway'a albo z czegoś podobnego.
Niestety automaty nie są w stanie zrozumieć pewnych rzeczy. Np. w podejściu continous delivery baza musi być w takim stanie żeby dało sie wycofać obecną wersję aplikacji jeżeli coś pójdzie nie tak. Zamiast więc np. usuwać kolumne z bazy, robi się ją null'owalną lub dodaje default.
Inna sprawa że człowiek jest też świadom że np. tabela jest bardzo duża i np. dodanie indeksu wprost może nie być najlepszym pomysłem. Lub że trzeba by pewną sztuczkę zastosować zrobioną specjalnie pod bazę X, lub wręcz migrować kawałkiem skomplikowanego kodu SQL żeby miało to szansę skończyć się w rozsądnym czasie.
Dlatego lepiej zadać pytanie czy można mieć toola który wygeneruje szablon migracji, która następnie zostanie zaakceptowana lub zmieniona przez człowieka. W C# z Entity Framework jest to możliwe.
W Javie z niczym podobnym się nie spotkałem na komercyjnym projekcie, ale w sieci ludzie robią sztuczki (https://www.sipios.com/blog-tech/generate-spring-boot-migrations-from-hibernate-entities) bazujące na tym że Hibernate może regenerować lokalną bazę a Liquibase posiada komendę diff którą tworzy migrację na podstawie różnic w schematach dwóch baz danych.
PS. Jeżeli piszesz cruderskie crudy to być może potrzeba Ci frameworka na miarę Rails'ów, np. https://www.jhipster.tech/creating-an-entity/ generuje Ci prawie wszystko od GUI po bazę.
0xmarcin napisał(a):
PS. Jeżeli piszesz cruderskie crudy to być może potrzeba Ci frameworka na miarę Rails'ów, np. https://www.jhipster.tech/creating-an-entity/ generuje Ci prawie wszystko od GUI po bazę.
W ekosystemie JVM odpowiednikiem Rails jest Grails, nawiasem mówiąc pod maską używa Hibernate, choć mocno nietypowo.
@Xorxorxor: To zależy, co rozumiesz przez pojęcie „nowe CRUD-y”. Jeżeli jest, to kod napisany od zera. Wepchnięty do bazy i już nigdy nie będzie zmieniany, to można od biedy skonfigurować JPA(Hibernate) tak, by przy uruchomieniu aktualizował schemat. Jednak nie jest to najlepsza opcja jeżeli schemat będzie się zmieniać. Zmiany powinien obsługiwać czy to Liquidbase czy Flyway(L/F), które mają wbudowane mechanizmy pozwalające na wycofywanie zmian oraz znacznie lepiej wspierają wersjonowanie schematów.
Rozumiem „lenistwo” przy przygotowaniu inicjalizacji, bo nikomu nie chce się klepać sqla. Dlatego warto zastosować podejście pośrednie.
Masz nowy moduł/CRUD, w którym zdefiniowałeś sobie mapowiania. Następnie bierzesz plugin do mavena, który wygeneruje za ciebie DDLe, które to DDLe umieścisz w odpowiednich katalogach L/F. W ten sposób masz „odwaloną” żmudną część pracy.
Realizujesz już za pomocą skryptów L/F. Przy czym w konfiguracji JPA podajesz, żeby przy starcie walidował schemat.
A jak wygląda poprawne wgrywanie skryptów flywayowych do bazy danych, i związana z tym komunikacja w zespole?
Przy okazji taki problem do rozważenia: osoba A i B pracują jednocześnie nad skryptami V1_2 i V1_3, respektywnie. Jeśli osoba B wgra swój skrypt przed osobą A, to potem osoba A nie będzie mogła wgrać swojego skryptu.
Z pomocą przychodzi out-of-order ustawiony na true, ale wtedy też mogą się pojawić kłopoty i to w dziwnych momentach, jeśli V1_2 i V1_3 są od siebie zależne (w sensie konfliktowe). W sytuacji konfliktowej trzeba by robić undo migration, czy jak?
Tak więc:
@Xorxorxor: to akurat nie jest poważny problem, ponieważ flyway ma mechanizm składowania migracji w bazie danych » https://flywaydb.org/documentation/getstarted/how po prostu trzeba to uruchomić :)