Zwingend den Hibernate Dialekt konfigurieren?

Wer mit Hibernate arbeitet muss eine persistence.xml im Classpath unterhalb des Ordners META-INF liegen haben. Die wichtigsten Konfigurationsparameter sind normalerweise der Transaktionstyp oder der Datasource JNDI Name, der Provider, die Entitäten (jar Datei oder Klassenangabe) und normalerweise der Datenbankdialekt. Im Regefall sieht sie dann wie folgt (oder ähnlich) aus:

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
  version="1.0">

  <persistence-unit name="MyEJBApp">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <jta-data-source>java:/MyEJBAppDatasource</jta-data-source>
    <properties>
      <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
      <property name="hibernate.hbm2ddl.auto" value="validate"/>
      <property name="hibernate.show_sql" value="true"/>
      <property name="hibernate.format_sql" value="true"/>
    </properties>
  </persistence-unit>
</persistence>

Der interessante Punkt ist die Angabe des Hibernate Dialekts. Dieser wird mit dem Schlüsselwort hibernate.dialect konfiguriert:

<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>

Es werden von Hibernate relativ viele Dialekte angeboten, so dass eine breite Unterstützung für die verschiedenen Datenbanken besteht. Unter den Angebotenen sind die üblichen Verdächtigen wie z.B.

und noch einige andere.

Was ich bisher nicht wusste ist, dass die Angabe des Dialektes optional ist. Lässt man die Angabe weg versucht Hibernate die korrekte Implementierung von org.hibernate.dialect.Dialect anhand der JDBC Metadaten herauszufinden die vom JDBC Treiber zurückgegeben/geliefert werden.
Für die gängigsten Datenbanken sollte es somit kein Problem sein den Dialekt einfach wegzulassen. Der große Vorteil an dieser Stelle wäre, dass man tatsächlich ein EAR relativ unabhängig von der Datenbank ausliefern könnte. Entscheidet man sich für das weglassen sollte man zumindest den Hibernate Konfigurationsparamater auf validate setzen um eine DB Schemavalidierung beim Starten der Anwendung zu haben.

<property name="hibernate.hbm2ddl.auto" value="validate"/>

Stimmt etwas mit dem für den dynamisch gefundenen Datenbankdialekt das Schema nicht würde zumindest eine Exception geworfen werden.

Nachlesen kann man das in der offiziellen Hibernate Dokumenation im Kapitel 3.4 unter “Optional configuration properties”. Gleich der erste beschriebene Parameter ist der hibernate.dialect.
In Kapitel 3.4.1, weiter unten auf dieser Seite, sind zudem alle implementierten Dialekte aufgelistet.

Tags: , , ,

Wenn du Fragen oder Anregungen zum Post hast, dann hinterlasse doch ein Kommentar oder wenn du weiterhin Artikel von Javathreads lesen möchtest, dann abonniere den RSS Feed und sehe direkt in deinem Feed Reader die nächsten Artikel.

Ähnliche Artikel, die dich interessieren könnten:
Kommentare

Nett :) Genau um sowas wollt ich mich auch noch kümmern in den nächsten Tagen mal. Hab da schon mit nem Arbeitskollegen drüber gesprochen.

Danke, der Artikel ist sehr informativ. :)

Perfekt, das spart mir gerade viel Forschungsarbeit :-) .

Also ich hab das jetzt gerade mal mit einer DB2 ausprobiert. Da meckert Hibernate aber, dass der Dialekt gesetzt werden muss.

Aber du hast ja geschrieben, dass das nicht immer funktioniert.

Gruß
Stefan

Interessant, dass es mit der DB2 nicht funktioniert.
In meinen Tests funktioniert das ohne Probleme mit der Oracle, PostgreSQL und HSQLDB (unter Verwendung des JBoss AS).

Könnte auch daran liegen, dass ich das Ganze (noch) als lokale Ressource und nicht als JTA laufen lasse.

Hinterlasse ein Kommentar