[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2933) externalize automatic resolution of Dialect (Tomoto Shimizu Washio)

[Tomoto Shimizu Washio (JIRA)]

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

Tomoto Shimizu Washio commented on HHH-2933:
--------------------------------------------

Thank you very much for working on this issue as well as answering to my questions!

I think passing DatabaseMetaData would be still fine.  It could eliminate connection.getMetaData() invocation and save one line from each DialectResolver implementation.  If you prefer this (actually I do), please change the interface.

As for SQLException...

I noticed that each method on DatabaseMetaData could throw SQLException when the JDBC driver did not support the requested metadata.  This means it would be difficult for DialectResolver to tell if the error was really caused by the connection problem (the process should be stopped) or just this JDBC driver did not support the information that the resolver required (this resolver does not handle this connection).

Said that, if it were important to distinguish those two cases, I think the following strategy should work: have a contract where "it is DialectResolver's responsibility to avoid to access to unsupported metadata so that throwing SQLException would always mean the connection problem that should stop the determination process".  Then, let DialectResolverSet not suppress SQLException.  Now SQLException thrown by a resolver is caught by DialectFactory and the determination process is stopped immediately.
Also, I would rather pass the database name and the database major version to the resolver along with the connection (or metadata) to ensure that the resolver could at least determine if the JDBC driver is known and which metadata are supported on this JDBC driver before accessing to any metadata.
And, although we might think of allowing DialectResolver to throw only HibernateException but not SQLException, I doubt it would be really necessary.  Given SQLException meant connection errors as discussed above, the handling process of this exception would not be resolver-dependent and it would be enough to have one handling process in DialectFactory layer.

Hope it helps, and please let me know if I could be of help.

> externalize automatic resolution of Dialect (Tomoto Shimizu Washio)
> -------------------------------------------------------------------
>
>                 Key: HHH-2933
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2933
>             Project: Hibernate Core
>          Issue Type: Patch
>          Components: core
>    Affects Versions: 3.2.5
>            Reporter: Mikael Kopteff
>            Assignee: Steve Ebersole
>             Fix For: 3.2.x, 3.3.x, 3.4
>
>         Attachments: dialect_registration.zip, dialect_registration_rev2.zip
>
>
> Introducing DialectResolver!
> Much better approach to resolving JDBC Connection information to Dialect allowing users to define custom behavior

-- 
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