JPA - potrzebne to w 2020?

JPA - potrzebne to w 2020?
Grzyboo
  • Rejestracja:ponad 9 lat
  • Ostatnio:5 miesięcy
  • Postów:206
0

Jak w temacie.

Jak taki zestaw technologii do obsługi bazy danych wygląda po wyrzuceniu JPA? Liquibase + JooQ?
Jak ze zmianami na bazie danych, np. dodawanie nowych kolumn? Hibernate to dosyć bezboleśnie załatwia, a definicja tabeli rozbita na kilka changesetów liquibase trochę zalatuje bałaganem.
Jak z testowalnością?

Obawy mam przede wszystkim o operacje CrUDowe. Takie JdbcTemplate lub JooQ działają fantastycznie do odczytu danych z bazy, ale czy nie ma kłopotów przy dodawaniu nowych rekordów, aktualizacji całych rekordów, usuwaniu rekordów.

Charles_Ray
  • Rejestracja:około 17 lat
  • Ostatnio:3 minuty
  • Postów:1875
4

Propozycja kolejna: nie wyrzucać JPA ;)

Jak ze zmianami na bazie danych, np. dodawanie nowych kolumn? Hibernate to dosyć bezboleśnie załatwia, a definicja tabeli rozbita na kilka changesetów liquibase trochę zalatuje bałaganem.
IMHO wręcz przeciwnie, masz udokumentowane zmiany schematu, które wprowadzasz świadomie i możesz je ładnie zaaplikować na wielu środowiskach. Nigdy na produkcji nie puściłbym Hibernate z włączonym ddl-auto.


”Engineering is easy. People are hard.” Bill Coughran
Grzyboo
Zostawianie JPA nie wchodzi w grę. Wkurza mnie, a poza tym chciałbym spróbować czegoś nowego :P Co do zmian schematu to faktycznie jest to niezła dokumentacja.
AK
  • Rejestracja:prawie 7 lat
  • Ostatnio:około miesiąc
  • Postów:3561
2

Ja mam dobre wrażenie z projektem JDBI. Między innymi w jednym z rozszerzeń potrafi wykorzystać adnotacje JPA na encjach (niektóre)

W aplikacjach webowych sesja JPA, obiekty attached to ZUPEŁNIE nie przystaje do rytmu webowego. Gdyby w JPA były kwerendy obiektów 'nie przeznaczonych do aktualizacji', bez całej otoczki proxy, stanu itd, to by odpowiadało dzisiejszym realiom (tak myślę) *)

Podobnie jak Tobie, porzucając, żal by mi było wieloplatformowego kreowania / aktualizowania bazy

*) sesja JPA moim zdaniem miała swój sens przy aplikacjach destopowych, nawet można była na to liczyć (odwrotnie w webie: tzreba z tym walczyć)


Bo C to najlepszy język, każdy uczeń ci to powie
edytowany 1x, ostatnio: AnyKtokolwiek
KamilAdam
  • Rejestracja:ponad 6 lat
  • Ostatnio:około miesiąc
  • Lokalizacja:Silesia/Marki
  • Postów:5505
1

Do zapisów jak ktoś lubi magię to JPA może zostać, ale do odczytów jest lepsze JOOQ lub JDBI

Pozwalać Hibernatowi lub innemu dostawcy JPA modyfikować schemat bazy na produkcji jest skrają nieodpowiedzialnością.
To już szybciej widziałem, że ktoś tworzył nowy schemat za pomocą Hibernate, a potem generował różnicę między schematem developerskim a produkcyjnym i później aplikował to na produkcji


Mama called me disappointment, Papa called me fat
Każdego eksperta można zastąpić backendowcem który ma się douczyć po godzinach. Tak zostałem ekspertem AI, Neo4j i Nest.js . Przez mianowanie
edytowany 3x, ostatnio: KamilAdam
Zobacz pozostały 1 komentarz
Grzyboo
A jak ktoś magii nie lubi i JPA nie chce zostawiać? Co wtedy? Ręczne pisanie insertów i update'ów raczej nie brzmi kusząco.
AK
@Grzyboo: nie rozumiem w jakiej konwencji zadajesz to pytanie, pytasz o wiedzę, chcesz ożywić dyskusję tzw "włożyć kij w mrowisko", czy jeszcze co innego?
Grzyboo
Chcę poznać alternatywy i dowiedzieć się jak żyć bez repository.save(entity) i jednocześnie nie wpaść w zbyt "niskopoziomowe" SQL.
AK
Projektów mapujących obiekty do bazy jest 8-10. Ze 3/4 z nich ma działanie przez konwencję (zgodność nazwy pola), czyli wtedy nie tzreba pisac kodu mapującego. W przypadkach bardziej skomplikowanych trzeba sobie zmapować. Jak już pisałem, w JDBI tym mapowaniem mogą być ... adnotacje JPA.
AK
MyBatis (dawniej iBatis), spark-java, jdbi, deltaspike, jooq, querydsl, sql2o i inne

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.