Hibernate 4: Was ist neu?

Laden über natürliche Schlüssel

Das Laden über natürliche Schlüssel, die mit @NaturalId gemappt sind, war bis zur Version 4.1 von Hibernate nur über Criteria Queries möglich. Hibernate 4.1 führt hierfür ein API ein. Neu hinzugekommen sind primär die Methode session.byNaturalId(..),die einen NaturalIdLoadAccess zurückgibt, auf dem man dann mithilfe der Methode using(.)die einzelnen Attribute spezifizieren kann. Hat eine Entität nur ein einziges Feld mit einem natürlichen Schlüssel, so kann mit session.bySimpleNatrualId(.)gearbeitet werden. Im Unterschied zu dem Laden von Entitäten über natürliche Schlüssel mithilfe von Criteria sieht das Hibernate 4 API über by(Simple)NatrualId auch Unterstützung für die Semantiken von load(..),wir laden sofort, und getReference(),wir erstellen einen Proxy und laden lazy bei Zugriff auf den Proxy, vor. Betrachten wir ein einfaches Beispiel indem wir eine Kreditkarte auf Basis ihrer Nummer, die den natürlichen Schlüssel bildet, laden:

@Entity
public class CreditCard {
  @Id
  private long id;

  @NaturalId
  private String number;
  ...
}

Die einfachste Variante, eine Kreditkarte über ihre Nummer mithilfe des neuen API zu laden, ist die Verwendung von bySimpleNaturalId().Dies ist möglich, weil die Entität nur ein Attribut besitzt, das mit @NaturalId gemappt ist:

session.bySimpleNaturalId(CreditCard.class).load(1234123412341234);

Alternativ besteht die Möglichkeit, einzelne Attribute mithilfe von byNaturalId(..)zu adressieren. Bitte beachten Sie weiterhin den Einsatz von getReference(..)anstelle von load(..):

session.byNaturalId(CreditCard.class).using(„number“, 1234123412341234).getReference();

Services und die Service Registry

Services sind in Hibernate Interfaces und deren Implementierung, die bestimmte Funktionen bereitstellen. Als Entwickler haben wir die Möglichkeit das Verhalten dieser Services zu verändern, indem wir die Standardimplementierung mithilfe von Vererbung überschreiben. Des Weiteren kann die bestehende Menge von Diensten um neue erweitert werden.

In Hibernate 4 werden die eben genannten Services durch die Service Registry verwaltet. Die Service Registry ist außerdem die zentrale Anlaufstelle für den Zugriff und das Registrieren von Services. Von den Standardservices, die mit Hibernate ausgeliefert werden, haben wir bei der Einführung der Mandantenfähigkeit schon den MultiTenantConnectionProvider kennengelernt. Weitere Services sind u. a.: Dienste für die JTA-Implementierungen einzelner Applikationsserver, der JMX-Dienst, die Konfiguration von Hibernate, das Auflösen von SQL-Dialekten oder ein JNDI-Dienst, der JNDI-spezifische Funktionen für Hibernate bereitstellt. Neben der BootstrapServiceRegistry, die das minimale Set an Services enthält, gibt es noch das Konzept der Integrators. Diese sind eine neue Möglichkeit um das Hochfahren der SessionFactory zu beeinflussen. Ein eigener Integrator muss das Interface org.hibernate.integrator.spi.Integrator implementieren. Über die Methode integrate()kann man sich in den Prozess des Hochfahrens einklinken, wohingegen disintegrate()eine Beeinflussung des Herunterfahrens der SessionFactory ermöglicht.

Migration auf Hibernate 4

Will man von Hibernate 3 auf die neueste Version migrieren, gilt es einige Aspekte zu beachten, die in der Dokumentation von Hibernate noch nicht ganz transparent dargestellt sind. Diese möchte ich hier kurz zusammenfassen. Im Rahmen der Migration auf Services haben sich einige Werte von Konfigurationsparametern geändert. So wurden zum Beispiel die Provider für den Second Level Cache umgezogen, als Service implementiert und umbenannt. Der Konfigurationsparameter hibernate.cache.provider_class in hibernate.cache.region.factory_class wurde umbenannt und die Ausprägung änderte sich von org.hibernate.cache.EhCacheProvider auf org.hibernate.cache.ehcache.EhCacheRegionFactory .

Weiterhin sollte man im Umfeld von Caches die Benennungen der Default Cache Regions in der jeweiligen Cache Konfiguration prüfen. Aus org.hibernate.cache.StandardQueryCache wird org.hibernate.cache.internal.StandardQueryCache und aus org.hibernate.cache.UpdateTimestampsCache wird org.hibernate.cache.spi.UpdateTimestampsCache .

Listener können nicht mehr über die Konfiguration hibernate.cfg.xml registriert werden. Diese sind künftig über die eben erwähnten Integrators an der SessionFactory zu registrieren.

Falls Sie UserTypes verwenden, sollten Sie die Methoden nullSafeGet und nullSafeSet auf die neue Signatur umziehen. Des Weiteren wurde session.connection()abgelöst. Für Arbeiten auf nativer JDBC-Ebene stehen Ihnen in Zukunft session.doWork(..) und session.doReturningWork(..)zur Verfügung.

Bei dem Einsatz von nativen SQL-Abfragen mit Skalaren sollte man noch darauf achten, dass sich die Spezifikation des Typs der Skalar-Spalten geändert hat. Die Hibernate-3.x-kompatible Abfrage in Listing 2 kann in Version 4 aufgrund der Verwendung von Hibernate.STRING in addScalar(..)nicht mehr verwendet werden.

Listing 2
List list = getSession()
  .createSQLQuery("select article_type, count(*) from Articles" +
                        "group by article_id " +
                        "order by count desc "
                        )
  .addScalar("article_id", Hibernate.STRING)
  .addScalar("count", Hibernate.LONG)
  .list();
Kommentare

Schreibe einen Kommentar

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