I went ahead and got something in for CR1. Take a look... On Wed, May 27, 2015 at 8:50 AM, Steve Ebersole <st...@hibernate.org> wrote:
> I actually started with the third approach. But you bring up a good point > about allowing the Dialect to access the DatabaseMetaData (and hence > Connection) if it wanted to. So I would change that a bit. See the > updated gist > > On Wed, May 27, 2015 at 7:33 AM, Max Rydahl Andersen <mande...@redhat.com> > wrote: > >> >> > 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 >> >> Of these I think the outline in "first approach" is the best >> since it does give the Dialect a chance to actually "talk" to the >> server to figure out a possible better lookup than the jdbcDriver does. >> >> But as you said the dialect must handle getting null passed in - just >> don't >> see a better way to handle that. >> >> Could even keep the implicit contract of if you return null it will >> do as described in "second approach" and have a decent fallback. >> >> /max >> >> >> > >> > >> > >> >> 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. >> >> >> /max >> http://about.me/maxandersen >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
