# Datenbankoperationen bei Hibernate bei evtl. Releasewechsel



## sparrow (31. Jan 2008)

Hallo Forum,

das Topic ist Mist aber ich hab keine Ahnung wie ich das sonst umschreiben soll.

Angenommen ich habe ein Softwareprojekt und nutze Hibernate als Mapper.
Wie gehe ich dann zukünftig mal vor wenn ich ein Release des Projekts freigebe das uU die Tabellenstruktur anpassen muss?

Ohne Hibernate würde ich einfach in einer Tabelle die "Versionen" der verschiedenen Tabellenstrukturen hinein schreiben und beim Start des Programms prüfen ob die aktuellen Versionen auch da sind. Falls dem nicht so ist würde ich im Programm die entsprechenden SQL-Befehle hinterlegen um die Struktur auf den neuesten Stand zu bringen.

Wie aber mache ich das am geschicktesten wenn Hibernate dazwischen hängt? Da kann/sollte ich ja nicht direkt auf der Datenbank arbeiten.


Gruß
Sparrow


----------



## tuxedo (31. Jan 2008)

Hmm, ich würde das noch vor der eigentlichen Anwendung prüfen. Quasi eine art Loader der beim Programmstart checkt ob die Grundvorraussetzungen (u.a. die DB Struktur) noch passend sind. Der Loader könnte dann per "nicht hibernate" die DB Struktur anpassen (also die entsprechdnden ALTER-Statements ausführen) und die Mappings gegen die neuen austauschen. Danach wird das eigentliche Programm gestartet. 

- Alex


----------



## sparrow (31. Jan 2008)

Hallo alex,

schön dich mal wider zu lesen 


Das Problem dabei ist nur, dass ich Hibernate eigentlich deshalb verwenden möchte damit das Programm an sich völlig unabhängig von der eingesetzten Datenbank ist.
Standardmäßig bring das Programm HSQLDB mit, so dass man starten kann ohne viel konfigurieren zu müssen.
Mit ein paar kleinen Änderungen in der Config-Datei läuft das Ding aber auch mit jeder anderen Datenbank die Hibernate bedienen kann. Feine Sache für den User. Dummes Problem für micht


----------



## tuxedo (31. Jan 2008)

Hmm, stimmt. Naja. Bin in Hibernate nicht fit. Aber mit iBatis könntest du auch den Loader DB-Unabhängig machen. Dummerweise  müssten dann die Mappings/Configs im Loader auch zur DB passen.

D.h. bei ner änderung der DB-Struktur müsstest du dem neuen Loader, auch eine passende Config mitgeben. "Hinbiegen" lässt sich das auf jeden Fall. SInd dann halt nicht ganz so "sinnvolle" Mappings in der Configurationo von iBatis/Hibernate...

- Alex


----------



## Guest (31. Jan 2008)

Beim Start der Anwendung in einem von dir festgelegten Verzeichnis nach Updates schauen, welche u.a.
ein Migrationsskript/programm enthalten und diese ausführen. Einfach wie fi...


----------



## tuxedo (31. Jan 2008)

Lesen hilft... Ganz so einfach ist es nicht. Geht ja um die Datenbankabstraktion. D.h. das Update muss zur verwendeten DB passen.

- Alex


----------



## ms (1. Feb 2008)

Hibernate bietet ja grundsätzlich die Funktion DDLs generieren zu lassen. Sowohl zum Erstellen als auch zum Aktualisieren. (hibernate.hbm2ddl.auto = validate | update | create | create-drop).
Die zugrundeliegende Klasse ist der Schemagenerator den man klarerweise auch programmatisch verwenden kann.
Damit lässt sich so ein Aktualisierungsszenario wie du es möchtest eingschränkt aber dafür Datenbankunabhängig implementieren.
Eingeschränkt deshalb, weil Löschvorgänge und erforderliche Datenmanipulationen natürlich nicht abgedeckt sind.
Also wenn einfach nur die Datenbank um Tabellen, Spalten bzw. Relationen in Tabellen usw. erweitert werden soll sollte es keine Probleme geben. 
Grundlage für den Schemagenerator sind natürlich die Mappings.

ms


----------



## sparrow (1. Feb 2008)

Hallo ms,

jap, so wäre es kein Problem neue Spalten einzuführen. Probleme gibt es halt nur bei tiefgreifenden Eingriffen in die Datenbankstruktur.
Da muss man dann entweder mauscheln oder ein Migrationstool basteln... das sollte dann aber nur bei großen Releasewechseln zum Einsatz kommen müssen.


----------

