Waking up to EclipseLink

Embbeded Database: H2

Einerseits wäre ein ORM-Framework ohne eine relationale Datenbank so gut wie nutzlos. Anderseits musste es möglich sein, Jubula ohne Weiteres in einer Eclipse IDE zu installieren und auszuprobieren. Mit der H2-Datenbank [4] konnten wir eine „integrierte“, dateibasierte Datenbank mit Jubula ausliefern. Sinnvolle Standardeinstellungen für H2 sorgen immer noch dafür, dass viele Nutzer nicht sofort merken, dass sie überhaupt eine Datenbank verwenden. H2 ist im Orbit-Projekt [5] als Bundle verfügbar.

Weitere Datenbanken

Das Arbeiten mit weiteren Datenbanken ist erst möglich, wenn die entsprechenden JDBC-Treiber vorhanden sind. Da die Lizenzen für die Treiber aber nicht EPL-kompatibel sind und die Treiber daher nicht über eclipse.org veröffentlicht werden durften, sind wir auf den Markt gegangen: Eclipse Marketplace [6]. Im Eclipse Marketplace stellen wir ein Fragment mit JDBC-Treibern für drei übliche Datenbanken (Oracle Database, MySQL und PostgreSQL) zur Verfügung. Und jetzt kann ein Benutzer, sobald die integrierte H2-Datenbank nicht mehr genügt (z. B. weil er mit mehreren Kollegen am gleichen Projekt zusammen arbeiten will), ohne größeren Aufwand das „Eclipse Jubula Database Drivers“-Fragment vom Eclipse Marketplace holen, um mit seiner schon vorhandenen Datenbank zu arbeiten. Die Backend-Logistik war geregelt, nun konnten wir uns wieder auf der ORM-Umstellung konzentrieren.

JPA

EclipseLink implementiert das Java Persistence API (JPA) und ist sogar eine Referenzimplementierung. Hibernate bietet ebenfalls das JPA an. Das machte die Umstellung von Hibernate JPA auf EclipseLink JPA relativ überschaubar und schmerzlos. Die Umstellung von Hibernate (Codebasis von 2004 ohne strukturelle Änderungen) auf Hibernate JPA war deutlich komplizierter, passt aber nicht unbedingt in diesen Artikel. Allerdings gab es trotz reibungsloser JPA-Umstellung einige Stellen, wo JPA selber keine Lösung anbietet. Hier mussten wir tatsächlich Hibernate-spezifischen Code durch EclipseLink-spezifische Coden ersetzen.

DDL

Die meisten ORM-Frameworks können DDL (Data Definition Language) aus Sourcecode und Konfigurationsdateien generieren und anwenden, um beispielsweise initiale Datenbanktabellen zu erstellen, zu löschen oder deren Struktur zu ändern. Obwohl DDL-Generierung von vielen JPA-Anbietern unterstützt wird, bietet JPA selber kein API dafür. Demzufolge muss man das konkrete API des eingesetzten Frameworks verwenden, in unserem Fall EclipseLink.

Jubula benutzt die DDL-Generierung, um den Installations- und Migrationsprozess von einer älteren Version auf eine neuere zu vereinfachen. Beim Verbindungsaufbau zur Datenbank wird von Jubula geprüft, ob einerseits die nötigen Tabellen vorhanden sind, und andererseits, ob diese auch die aktuelle Struktur besitzen. Fehlen Tabellen, so werden sie automatisch angelegt. Falls die entsprechenden Tabellen bereits vorhanden sind, aber von einer älteren Jubula-Version angelegt wurden, folgt eine automatische Migration auf die neue Tabellenstruktur. Die Idee dahinter ist, dass man kein Datenbankadministrator sein muss, um Jubula installieren und benutzen zu können.

Die DDL-Generierungs-APIs für Hibernate und EclipseLink sind sehr ähnlich: Hibernate stellt die Klasse org.hibernate.tool.hbm2ddl.SchemaExport bereit, während in EclipseLink die Klasse org.eclipse.persistence.tools.schemaframework.SchemaManager verwendet werden kann. Beide Klassen haben jeweils Methoden, um Tabellen entsprechend zu einem bestimmten Objektmodell zu erstellen beziehungsweise zu löschen. Dementsprechend war es beinahe trivial, die DDL-Generierung auf EclipseLink umzustellen. Der einzige Haken war, dass die von EclipseLink generierten Constraints zum Teil sehr unterschiedliche Bezeichner tragen als die von Hibernate generierten. Daraus hat sich der folgende Ablauf entwickelt:

  1. EclipseLink kann bestimmte Constraints nicht löschen.
  2. Da verschiedene Constraints noch in der Datenbank stehen, kann EclipseLink bestimmte Tabellen nicht löschen.
  3. Da verschiedene Tabellen (mit der veralteten Struktur) noch beziehungsweise schon in der Datenbank stehen, kann EclipseLink entsprechende neue Tabellen (mit der aktuellen Struktur) nicht anlegen.

Seiner Spezifikation gemäß ignoriert EclipseLink alle Database Exceptions, die aus diesem Prozess entstehen. Das Problem fällt erst auf, wenn die Strukturunterschiede irgendwann später zu völlig irritierenden Fehler führen. Dieses Problem haben wir gelöst, indem wir unseren Migrationsassistenten für das erste Release mit EclipseLink „unter der Haube“ ausgeschaltet haben. Ab der nächsten Version ist diese Funktionalität wieder im Einsatz, und dann verschwindet das letzte Relikt Hibernates aus Jubula.

Was hat man eigentlich davon?

Jubulas Umstellung auf EclipseLink war ein notwendiger Schritt, um ein Eclipse-Projekt zu werden. Aber auch andere Eclipse-basierte Projekte können von solch einer Umstellung profitieren. Die Konfiguration, um im OSGi-Kontext zu laufen, wird vereinfacht, und die Unterstützung der Eclipse-Community (mit der Entwickler Eclipse-basierter Projekte bestimmt schon Kontakt haben) ist dabei auch nicht zu unterschätzen. Zusammen mit H2 kann man eine schlanke Persistenzlösung implementieren, die durch simple Konfiguration auch mit großen Datenbanken arbeiten kann. Letztendlich muss jedes Projekt für sich selbst entscheiden. Für diejenigen, die diese Umstellung vornehmen und vielleicht auch funktionale Regressionstests dafür einführen wollen, kann ich ein sehr gutes UI Test Eclipse Package empfehlen.

Zeb Ford-Reitz ist Eclipse Committer im UI-Testautomatisierungsprojekt Jubula. Als Entwickler bei der BREDEX GmbH ist er seit 2006 auch am Jubulas kommerziellem „großem Bruder“ GUIdancer beteiligt.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.