To zależy od projektu. Właściwie wypróbowałem wszystkie możliwe opcje w różnych projektach. Tworzenie changesetów w XMLu stosowałem w projekcie, który był developowany w Postgresie, a na produkcji działał na Mssql. I generalnie działało to całkiem dobrze, nie było większych problemów. Taka była specyfika tego projektu (ale to raczej rzadkość).

Słyszałem też, że inni stosują XMLa w projektach z jednym silnikiem bazy. Oczywiście wygodnie jest pisać wszystko w sqlu i tak w większości przypadków to robię (jak korzystam z Oracla czy Mssql, to raczej nie przewiduję migracji bazy).

Oczywiście zachodzi ryzyko, że kiedyś będziesz chciał zmienić silnik bazy, wtedy będziesz musiał z migrować bazę (i to jest normalne), ale pytanie, czy też warto migrować wszystkie changesety? Chyba tak, jeśli chcemy, żeby developerzy mogli odpalić projekt lokalnie od zera (bez zabawy w przenoszenie bazy z np. jakiegoś serwera testowego). I generalnie taka migracja changesetów jest bardzo trudna, bo hashe changesetów zapisują się we wszystkich bazach i generalnie trzeb kombinować jak to wszystko ogarnąć. Ale zmiany silnika zdarzają się raczej rzadko, więc nie jest to aż tak straszny scenariusz.

Potencjalnie jest wiele problemów związanych ze stosowaniem sql w changesetach…

Dzięki 😉

Dzięki 😉

No to w końcu poprawne czy nie? 😉 To nie jest problem ani wina Hibernate i mechanizmu hbm2ddl, że dev nie dodał @JoinColumn. Skąd biedny Hibernate ma wiedzieć którą kolumnę użyć jako FK bez anotacji @JoinColumn?

Trudno powiedzieć, nie wiem, czy ktoś zapomniał tej adnotacji, czy zrobił tak celowo 😉

Tak wiem, że można nadawać nazwy indeksom i kluczom obcym, tylko czy ktoś o tym pamięta?

Co do reszty, to dzięki za podzielenie się swoimi doświadczeniami 😉

No to w końcu poprawne czy nie? 😉 To nie jest problem ani wina Hibernate i mechanizmu hbm2ddl, że dev nie dodał @JoinColumn. Skąd biedny Hibernate ma wiedzieć którą kolumnę użyć jako FK bez anotacji @JoinColumn? 😛

„Hibernate nadaje im losowe nazwy np. „FK2VL1PWD258E41JNAM1CNC3VNA”. ”
Rozwiązanie:
https://docs.oracle.com/javaee/7/api/javax/persistence/Index.html#name–
https://docs.oracle.com/javaee/7/api/javax/persistence/ForeignKey.html#name–

Już gdzieś mieliśmy tą dyskusję. Jestem fanem jak najdokładniejszego opisania schematu za pomocą annotacji które dają JPA/Hibernate. Po to, żeby m.in. takich problemów nie mieć.

Osobiście w projektach używamy update + skrypty migracyjne (jeśli konieczne) wywoływane ręcznie + automat przy każdym starcie aplikacji dropuje wszystkie widoki i zakłada na nowo z odrębnego skryptu. Niektóre projekty tak już chodzą 8 lat. Skrypty migracyjne wersjonowane razem z WARem z releasu w VCSie. Zero problemów 😛

Jasne, jak wrócę do nagrywania to pomyślę o tym 😉