JPA - Objekt verändern

[RooKee]

Hey..

Ich habe eine Enitity User

@Entity
public class User {

protected String name;
protected String password;
...
}

Ich lasse die Tabellen und Felder von Hibernate generieren. Nun möchte ich aber nachträglich ein weiteres Feld hinzufügen "Email". Wie mache ich das am besten. Klar ich adde einfach das Feld in der Klasse aber dadurch sind dann ja alle bisherigen Objekt mit dem Wert null versehen. Muss ich jetzt jedes Element durchlaufen und wenn das Attribute null ist selber setzen? Gibt es nicht eine einfachere Methode?

Auch wenn ich ein Feld im nachhinein löschen will, kann ich das Attribute entfernen aber in der Datenbank sind die Felder denoch vorhanden... Hab keine Idee wie ich das lösen kann ohne selbe mit SQL die Tabelle zu modifizieren, was ich eigentlich nicht machen will.

Danke für die Hilfe

Gruß Markus

 

[bluer]

Beim Löschen einer Spalte gehe ich wie folgt vor:

• Daten der DB als SQL-File exportieren (z.B. mit HeidiSQL), wobei ich die gelöschten Spalten weglasse.
• Datenbank löschen.
• Datenbank wieder anlegen.
• Programm starten.
• SQL-FIle wieder importieren.

Beim hinzufügen von spalten gibt es meines Wissens nach keine Methode, außer die von dir beschriebene. Wenn jmd. eine kennt wäre auch dran interessiert, dann immer alles per Hand zu setzen ist unschön.

 

[maki]

Umgekehrt wird ein Schuh draus...

Unschön ist es, sich die Tabellen automatisch abändern zu lassen auf dem Prodsystem, war nur für die Entwicklung gedacht.
Richtig ist es, sein Schema selber anzupassen.

Ein ORM wie JPA/Hibernate entbindet einen nicht davon, sich gut mit RDBMS auszukennen und dem Mapping zwischen Objekten und RDBMS, ORM fördern keine Ignoranz, es geht um Bequemlichkeit, aber nicht auf kosten der Datenkonsistenz.

 

[Rookee2]

Naja gut, das mag gehene wenn man Zugriff auf die Datenbank hat. Aber z.B. bei der Google App Engine ist es nicht so einfach die Daten zu verändert, da man dort nur mit Objekten Arbeitet.

Und mal eben die Datenbank kicken ist ja wohl nen witz. Das kann doch kein ernst gemeinter Workflow sein...

 

[nillehammer]

Wenn Deine neue Spalte nullable ist, ist es doch kein Problem, wenn bei den bereits bestehenden Daten überall null steht. Falls es non null ist, hast Du halt die Probleme, die man bei inkompatiblen Migrationen hat. Um etwas SQL-Export/Import kommt man da halt nicht herum.

Und mal eben die Datenbank kicken ist ja wohl nen witz. Das kann doch kein ernst gemeinter Workflow sein...

Wenn die Datenbank im wesentlichen Stammdaten enthält, hast Du sie ja sicher schon automatisiert angelegt. Da kann dann auch Datenbank kicken und neu anlegen ein Weg sein. Bei einer Datenbank mit Bewegungsdaten (z.B. Bestellungen etc.) wohl eher nicht...

 

[Rookee2]

Ok beim hinzufügen von Spalten ok.

Aber wenn ich eine Löschen möchte... Meinet wegen wurde während des Betriebs festgestellt das z.B. eine 2. Vorname nicht mehr benötigt wird.
Wie stelle ich das an? Wenn ich das Attribute im Objekt kicke, dann werden die nächsten Objekte dieses Feld NULL setzen. Aber das Feld ist ja immer ncoh da.

Das muss doch funktionen ohne die Datenbank anzufassen bzw. nur mit JPA.

 

[maki]

Das muss doch funktionen ohne die Datenbank anzufassen bzw. nur mit JPA.

Nein, dafür ist JPA nicht da.

 

[nillehammer]

Wenn ich das Attribute im Objekt kicke, dann werden die nächsten Objekte dieses Feld NULL setzen. Aber das Feld ist ja immer ncoh da.

Stimmt beim DDL-Feature von Hibernate ist das so (Die Features von anderen ORM-Tools kenne ich leider nicht). Also entweder bei Hibernate create statt update benutzen (was im Prinzip ja "Datenbank kicken" ist) oder Spalte von Hand löschen.

Zur "Verteidigung" von Hibernate ein möglicher Grund für dieses Verhalten: Ein nicht gemapptes Atrtribut in einer Anwendung muss nicht automatisch bedeuten, dass eine Spalte nicht gebraucht wird. Immerhin kann es ja sein, dass auf eine Datenbank von mehreren Anwendungen aus zugegriffen wird. Ein Column-Drop würde der anderen Anwendung dann die Spalte unterm A***h weg ziehen.

 

[Rookee2]

Ok. Aber wie das Beispielsweise bei Google App Engine. Dort hat man keine Möglichkeit die Daten via SQL zu Ändern. Alles geschieht über JPA. Nach eurer Aussage hatte ich ein großes Problem wenn ich ein Feld in der Datenbank löschen möchte....

 

[nillehammer]

Du kannst ja jedes beliebige SQL-Statement per native Query auch über die JPA-Schicht absetzen. Die entsprechenden Rechte auf der Datenbank vorausgesetzt, kann das auch ein DROP COLUMN sein. Ich kenne die Google App Engine zwar nicht, kann mir aber vorstellen, dass JDBC auch direkt ohne ORM-Schicht funktionieren könnte.

 

[oopexpert]

Naja gut, das mag gehene wenn man Zugriff auf die Datenbank hat. Aber z.B. bei der Google App Engine ist es nicht so einfach die Daten zu verändert, da man dort nur mit Objekten Arbeitet.

Und mal eben die Datenbank kicken ist ja wohl nen witz. Das kann doch kein ernst gemeinter Workflow sein...

Für die Entwicklungsumgebung baue ich für jeden persistenten Testfall die Datenbank frisch auf.