> 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
