[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2933?page=c...
]
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira