Originalmente Hibernate siempre requería que los usuarios especificaran qué dialecto utilizar. En el caso de aquellos usuarios que buscaban apuntar a múltiples fundamentos de datos de forma simultánea con su construcción eso representaba un asunto. Generalmente esto requería que los usuarios configuraran el dialecto de Hibernate o que definieran su propio método para establecer ese valor.

Empezando con la versión 3.2 Hibernate introdujo la noción de detectar automáticamente el dialecto a utilizar con fundamento en los java.sql.DatafundamentoMetaData que se obtuvieron de una java.sql.Connection a esa fundamento de datos. Esto era mucho mejor pero esta resolución estaba limitada a las fundamentos de datos que Hibernate conoce por adelantado y de ninguna forma era configurable ni se podía sobreescribir.

Starting with version 3.3 Hibernate has a fare more powerful way to automatically determine which dialect to should be used by relying on a series of delegates which implement the org.hibernate.dialect.resolver.DialectResolver which defines only a single method

!-- --span class=java_keywordpublicspan!-- --span class=java_plainspan!-- --span class=java_typeDialectspan!-- --span class=java_plainresolveDialectspan!-- --span class=java_separator(span!-- --span class=java_typeDatabaseMetaDataspan!-- --span class=java_plainmetaDataspan!-- --span class=java_separator)span!-- --span class=java_plainspan!-- --span class=java_keywordthrowsspan!-- --span class=java_plainspan!-- --span class=java_typeJDBCConnectionExceptionspan
. The basic contract here is that if the resolver 'understands' the given database metadata then it returns the corresponding Dialect if not it returns null and the process continues to the next resolver. The signature also identifies org.hibernate.exception.JDBCConnectionException as possibly being thrown. A JDBCConnectionException here is interpreted to imply a non transient (aka non-recoverable) connection problem and is used to indicate an immediate stop to resolution attempts. All other exceptions result in a warning and continuing on to the next resolver.

La fracción divertida de estos resolvedores es que los usuarios también pueden registrar sus propios resolvedores personalizados los cuales se procesarán antes de los incluídos en Hibernate. Esto puede llegar a ser útil en un número de situaciones distintos faculta una fácil integración para la auto-detección de dialectos más allá de los que se envían junto con Hibernate le faculta especificar el uso de un dialecto personalizado cuando se reconoce una fundamento de datos en propia etc. Para registrar uno o más resolvedores simplemente especifiquelos (separados por comas o espacios) usando la configuración 'hibernate.dialect_resolvers' (consulte la constante DIALECT_RESOLVERS en org.hibernate.cfg.Environment).