On Wed, May 27, 2015 at 5:23 AM, Max Rydahl Andersen <manderse(a)redhat.com>
On 27 May 2015, at 5:49, Steve Ebersole wrote:
If anyone is interested, the issue is here:
> I do wonder overall about the interplay that should happen between a
> Dialect and the JdbcEnvironment.
I reckon your issue is that you need access to Dialect before you might
have a DatabaseMetaData so you can't give that to the Dialect to hold on
No, that is not my concern at all.
I absolutely do not want the Dialect to "hold on to" the DatabaseMetaData
if by that you mean holding it as instance state. I was really just
meaning for it to have access to the DatabaseMetaData for the duration of
this method call. This is actually part of a larger idea I have slowly
been evolving where we use the driver and the Dialect to build an
"understanding" of the capabilities of the underlying database. The old
way was calling one or more of the 50,000 (give or take ;) true/false
methods on Dialect at runtime. The new evolving approach is to build
delegates/helpers at boot time that encapsulate all that. Most of that
work so far is encapsulated by JdbcEnvironment. One piece of this
JdbcEnvironment is this IdentifierHelper
Maybe it makes the most sense to psuedo-code some approaches:
One concern about DatabaseMetaData that hit the tools a few times is
getting this can be extremely expensive for some drivers (I don't recall
exactly, but Oracle comes to mind ;)
We get this once per bootstrap.