Jasne zabrakło tej adnotacji 😉 Dopisane

btw i ten
@AllArgsConst
Kto tego używa na encjach? Pierwszy raz widzę taki pomysł 😉

Dzięki za komentarz 😉 Tak, to prawda, że trzeba wiedzieć jak to działa, żeby tego prawidłowo używać.

W artykule chodziło mi o użycie adnotacji @Column bez żadnych parametrów, co nie daje żadnego efektu, lub tylko z parametrem name co jest nadmiarowe moim zdaniem. Jeśli używasz tej adnotacji, żeby określić pewne parametry to jest jak najbardziej ok.

Co do migracji to często występują jakieś przełomowe zmiany pomiędzy „dużymi” wersjami. I zastanów się czy nie lepiej jest wykonać pewną pracę przy migracji raz(może nawet trzeba będzie zmieniać nazwy kolumn) zamiast skazywać się na ciągłe dodawanie do encji @Column(name = „nazwa kolumny”).

W zeszłym tygodniu był problem z @Equals i @Hashcode gdzie przez stosowanie tych annotacji duplikowały się encje przy zapisie do DB. Wywalenie tych annotacji i ręczne napisanie equalsa naprawiło problem. Inny problem niedawno był jak było @ToString i była kolekcja @OneToMany i Hibernate wpadł w jakąś nieskończoną pętlę przy próbie wygenerowanie toStringa. Ręczny toString z pominięciem tej listy pomógł.
Na stacku jest parę problemów z Hibernate i Lombokiem: https://www.google.com/search?q=hibernate+lombok+problem+site:stackoverflow.com

Jeden kwiatek nie związany bezpośrednio z Lombok i Hibernate:
Miej w klasie (encji) dwa pola stringowe jedno po drugim:
private String fieldA;

prrivate String fieldB:

Zastosuj na klasie @AllArgsConstructor. Wykorzystaj ten kontstruktor i zapisz dane do bazy. Następnie zamień kolejnością te pola, zbuilduj i zapisz ponownie dane. Następnie sprawdź w jakich kolumnach wylądowały dane z pól fieldA i fieldB przy drugim zapisie 😉

Jeśli się wie jak to wszystko działa to można stosować. W mojej pracy się zrobił hype na lomboka w ostatnim roku. Niestety koledzy przychodzil kilka razy z podobnymi problemami jak opisanymi wyżej.

Racja, wersji hibernate’a nie zmienia się często, ale jak zmieniasz to wewnętrzne zachowanie hibernate może się zmienić. Takim wewnętrznym zachowaniem są np. Naming Strategies. Duża zmiana nastąpiła np. przy przejściu z 4.3 na 5.0: https://github.com/hibernate/hibernate-orm/blob/5.0/migration-guide.adoc#naming-strategies. Bierzesz nową wersję Hibernate’a i nagle Ci się schema nie waliduje. Nie chcę przy upgrade Hibernate’a musieć zmieniać strukturę bazy.
Zresztą nie podając @Column nie mam możliwości ustawienia czy kolumna jest not null. Nie mogę ustawić długości np. pola VARCHAR – po co mam PESEL zapisywać w kolumnie o długości 255? Nie mogę ustawić sobie prostego unique indexu na wyżej rzeczonym PESELu. Przy BigDecimalach nie mogę podać skali i precyzji.
Nie zgadzam się z tym, że powinno się dążyć do eliminacji tej i innych annotacji określających strukturę bazy. Wręcz przeciwnie. Zresztą podajesz też wyżej przykład z @JoinColumn(name=”user_id”) gdzie podajesz nazwę kolumny FK. Będą konsekwentnym powinieneś tego name’a nie podawać.

Używałem Lomboka z Hibernate i szczerze mówiąc nie miałem, większych problemów z tym połączeniem. Może podzielisz się jakimiś szczegółami. Chętnie poczytam.

zmieniasz wersję hibernate’a, zmieniasz PhysicalNamingStrategy

Wersji Hibernate’a nie zmienia się aż tak często. Pytanie po co zmieniasz PhysicalNamingStrategy? Jak nie zmienisz nie będziesz miał z tym problemu.

Niepotrzebna adnotacja @Column – zmieniasz wersję hibernate’a, zmieniasz PhysicalNamingStrategy i jesteś w ciemnej czarnej D. Albo masz pole, które Ci wygeneruje nazwę kolumny jak keyword zastrzeżony w danym serwerze BD. Nie musi to być dzisiaj. Klient sobie strzela upgrade SQL Servera z 2005 na 2019 – bum. Analogicznie można by zaproponować rezygnację z annotacji @Table(name=… .
Osobiście jestem fanem jak najsztywniejszego określenia struktury bazy w encji, łącznie z nazwami FK, indexami, itd. Daje mi to większe poczucie bezpieczeństwa.