On Wed, May 27, 2015 at 5:23 AM, Max Rydahl Andersen <mande...@redhat.com> wrote:
> On 27 May 2015, at 5:49, Steve Ebersole wrote: > > If anyone is interested, the issue is here: >> https://hibernate.atlassian.net/browse/HHH-9820 >> >> 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 > to ? > 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 (JdbcEnvironment#getIdentifierHelper). Maybe it makes the most sense to psuedo-code some approaches: https://gist.github.com/sebersole/46b5b7968e748648f562 > One concern about DatabaseMetaData that hit the tools a few times is that > getting this can be extremely expensive for some drivers (I don't recall > which > exactly, but Oracle comes to mind ;) > We get this once per bootstrap. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
