[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2933) DialectFactory dialects should be in a properties file

Steve Ebersole (JIRA) noreply at atlassian.com
Mon Sep 22 10:21:05 EDT 2008


    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31256#action_31256 ] 

Steve Ebersole commented on HHH-2933:
-------------------------------------

Tomoto, I appreciate the work you put into this and I largely like the result.  The one thing I would change would be to not have Dialects themselves involved at all in registration.  The reason being that many Dialects could register against a single set of connection metadata.  

Take an Oracle 8i database as an example...  Just in terms of Dialects Hibernate ships, we as end-users could conceivably want to use Oracle8iDialect, Oracle9iDialect Oracle10gDialect, DataDirectOracle9Dialect, etc depending on our requirements.  

The "finder" or "resolver" approach is better I think because it would allow explicit control over this facet.  Hibernate could provide a standard one that does the same basic thing we currently do with DialectFactory#MAPPERS.  This would also act as the "fallback" resolver, allowing custom-registered resolvers a chance to do resolution first.

Also, in terms of impl, I think it would be better to pass along the Connection for resolution rather than individual pieces of metadata information from the connection.  So I'd prefer:

public interface DialectResolver {
    /**
     * Determine the dialect to use based on the configured connection.  Implementations should
     * return null to indicate that they have no knowledge of which dialect to use for the given
     * connection.
     *
     * @param connection The connection
     *
     * @return The dialect we want used for this connection, or null if we cannot make such a determination.
     */
    public Dialect resolveDialect(Connection connection);
}

> DialectFactory dialects should be in a properties file
> ------------------------------------------------------
>
>                 Key: HHH-2933
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2933
>             Project: Hibernate Core
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.2.5
>            Reporter: Mikael Kopteff
>         Attachments: dialect_registration.zip
>
>
> Currently the DialectFactory has the static attribute MAPPERS, that hold the dialects. If the dialect is not found, Hibernate will throw an exception. There is already an TODO tag, set for this.So, could this be possibly done, so that the values really are a) in a properties file or b)additions could be made to the map programmaticaly by users.
> This would be more flexible for advanced users, that work with experimental jdbc drivers(that don't return a standard name for the database).
> The current trunk version of DialectFactory:
> // TODO : this is the stuff it'd be nice to move to a properties file or some other easily user-editable place
> 	private static final Map MAPPERS = new HashMap();
> 	static {
> 		MAPPERS.put( "HSQL Database Engine", new VersionInsensitiveMapper( "org.hibernate.dialect.HSQLDialect" ) );
> 		MAPPERS.put( "H2", new VersionInsensitiveMapper( "org.hibernate.dialect.H2Dialect" ) );
> 		MAPPERS.put( "MySQL", new VersionInsensitiveMapper( "org.hibernate.dialect.MySQLDialect" ) );
>                 etc.....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the hibernate-issues mailing list