To Gail's specific question... As Sanne stated, a new Dialect is the only option IMO for the moment.
But what Chris brings up is important, and something we really should start deciding. We have been discussing it off and on for 4-5 years. Dialects were originally designed to be inflexible. We can debate the merits of that decision, but it is what leads to the need for all these Dialect impls for seemingly trivial deviations. So there is also a long term discussion to be had here. However, it is not quite as cut-and-dried as you make out Sanne. Quite a few Dialects already "configure themselves" based on various things (e.g. take a look at the H2Dialect's ctor). The problem is that to-date there has not been a standard way to do that, especially in regards to gaining access to JDBC metadata as part of that self-config. The ideal solution would be to keep Dialects static/inflexible but to use that along with JDBC metadata to build a true understanding of how to interact with the database. Personally, I think it is easier to just simply let the Dialect configure itself. But there is a certain danger there, as there always is when completely changing the design of something, especially something that many many users use. We shall see that play out soon with Type :) On Thu, Feb 16, 2017 at 8:54 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 16 February 2017 at 14:23, Chris Cranford <cranc...@gmail.com> wrote: > > We have actually discussed doing something where Dialect's auto-configure > > themselves, but such a change would likely be appropriate for a major > > release only. > > > > On 02/16/2017 04:57 AM, Christian Beikov wrote: > >> How about a different approach? Like passing the DB version somehow to > >> the dialect so that it can decide for itself instead of having different > >> subclasses. > > People currently expect to be able to configure a Dialect by choosing > a specific classname. > > I don't disagree on exploring evolutions, but indeed I'd not change > such matters in a minor release; > > Gail needs a fix focusing on the cross join issue so a new class will > suffice for the immediate need. > > >> > >> Am 16.02.2017 um 08:16 schrieb Gail Badner: > >>> HHH-11487 can be fixed by using changing > DB2Dialect#getCrossJoinSeparator > >>> to return " cross join ". > >>> > >>> DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support > CROSS > >>> JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015. > >>> > >>> It's tempting to just update DB2Dialect, but I suspect that would break > >>> existing applications still using DB2 9.1. > >>> > >>> I'm considering adding a new dialect DB295Dialect that extends > DB2Dialect > >>> and overrides DB2Dialect#getCrossJoinSeparator to return "cross join". > >>> > >>> WDYT? > > +1 > > Thanks, > Sanne > > > >>> > >>> Regards, > >>> Gail > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
