Sziasztok!
Elkezdtem foglalkozni a JPA-val, és az a kérdés merült fel bennem, hogy ha már éles környezetben fut egy alkalmazás, és fejlesztés közben bővítem az entiásokat, akkor az az adatbázis oldalán hogyan fog megjelenni? Képes ezt a JPA automatikusan lekezelni? Tehát mikor az alkalmazást deployálom az alkalmazás szerverre akkor átvezeti a módosításokat az adatbázison? Vagy nekem kell az adatbázist DDL utasításokkal rendben tartani?
1.0 verzió:
@Entity
public class Person {
private int id;
private String name;
...
2.0 verzió:
@Entity
public class Person {
private int id;
private String name;
private int age;
...
3.0 verzió:
@Entity
public class Person {
private int id;
private String name;
private int age;
private String address;
...
Hozzászólások
Nem merem teljes biztonsággal állítani, de szerintem a JPA nem erre való. Inkább valami db migrációs eszközt javasolok, mondjuk Flyway vagy Liquibase.
+1
Mindenesetre meg tudja csinálni, ha autogenerate ddl be van kapcsolva, de nagyon erősen ellenjavallt, liquibase-t tudom ajánlani :)
+100
A DDL autogenerálás arra jó, hogy az "5 perc alatt teljes JPA alkalmazás!" jellegű tutorialokban használják. Éles projekten csak rendes DB schema migráló eszközt szabad használni (mint a fentebb említettek).
El kell fogadni, hogy a JPA egy ORM eszköz, és érteni kell, hogy milyen relációs séma van alatta, és miért.
A JPA implementációk elvileg képesek rá, hogy automatikusan frissítsék a sémát. Az más kérdés, hogy éles rendszeren ellenjavallt, de fejlesztés közben nagyon hasznos tud lenni.
Hibernate esetén a
hibernate.hbm2ddl.autoproperty-t kellupdate-re állítani.Mellesleg ha eléggé ügyes vagy, akkor éles rendszeren is össze lehet hozni, hogy menjen, de tisztában kell lenni a korlátaival, ami provider függő. Pl. legjobb tudomásom szerint a Hibernate csak hozzáadni tud táblát, mezőt, talán indexeket is, de meglévő táblákat nem tud törölni, illetve mezőket sem lehet vele törölni és módosítani.
Nekem volt egy projektem, kb 8 éve megy, 30 release ment ki, több száz telepítéssel rendelkezik, és a Hibernate-re bíztuk a schema update-et. Működik rendesen, de nagyon észnél kell lenni, és erősen függ az alkalmazástól is, hogy lehet-e/érdemes-e.
Élesben inkább a fentebb is említett Liquibase vagy Flyway. Vagy csinálod kézzel az SQL-eket, persze a Hibernate-től pl. el lehet kérni, hogy ő milyen DDL-t futtatna le :)
Tud módosítani mezőket bizonyos kereteken belül. Pl. olyan mezőből nem tud notnullost csinálni, aminek van olyan rekordja, amire ez nem teljesül - meg hasonlók. :)
Figyelni kell Hibernate generáció váltásra is; 4 -> 5-nél volt változás az obj -> név megfeleltetési mechanizmusban. Na most ez automatikusan létrehozott kapcsoló táblák, idegen kulcs megszorítások nevei, mezőneveinél gubancot és működésképtelen appot okoz, ha auto update-re van állítva. Migrálni kell az adatbázist és/vagy pontosítani az entity leírásokat.
Spring Boot verzióváltás tud ilyet okozni pl.
Pontosan ezek miatt nem szabad használni
Migrálni kell az adatbázist és/vagy pontosítani az entity leírásokat.
...vagy pedig csinálsz NamingStrategy-t, ami kompatibilis a régivel. Ráadásul az 5-ösben már tényleg mindenre lehet is.
Amíg lehet én nem vezetnék be JPA szint alatti dolgokat (mert nekem a JPA fontos inkább, mint a Hib), csak ha nincs más megoldás.
Ha jól értem, a fenti mondatod azt jelenti, hogy nem szívesen használsz JPA Vendor-specifikus vagy adatbázis-vendor specifikus dolgokat. Nem tudom, hogyan csinálod, de nekem még nem nagyon sikerült megúsznom, előbb-utóbb mindig kell valami, ezért viszont nem fázom tőle. NamingStrategy-t például azért is használunk, hogy "szebb" legyen a DB séma és könnyebb legyen hozzá szkripteket írni vagy kézzel piszkálni.
A múltkor például akkora eretnekséget csináltam, hogy az Oracle dialect-be gyártottam egy default ID generatort, ami táblanév_SEQ szekventiákat használt, mert aki megálmodta az adatbázist, az így tervezte, és minden entitás definícióban ott szerepelt a nyomorul szekvencia deklaráció, ugyanarra a sémára. A dialect felokosítás után már nem, ráadásul innen már könnyen ment áttenni másik motorra és azon futtatni teszteket ill. prototipizálásra használni automatic schema update-tel. Azaz pont azzal, hogy belenyúltam a "JPA alatti" dologba lett db vendor-független az alkalmazás.
Én szívem szerint magát a JPA-t felejteném el, sokkal jobban szeretem a Hibernate natív API-ját. Olyanról meg sosem hallottam, hogy valaki JPA providert váltott volna projekt közben...
Flyway vagy Liquibase. Nagyjából ugyanazt tudják, ugyanúgy, csak a részletekben van eltérés.
A JPA környéki dolgokat felejtsd el idejekorán. A hibernate féle update csak rapid prototipizálásra jó, ha már nem a lokális fejlesztésről van szó, akkor nem éri meg a kockázatot / odafigyelést.
--
arch,debian,retropie,osmc,android,windows