Right you could have the Dialects return the standard set by default,
then someone with specialistic knowledge of the specific database
could either override that with a custom Dialect or provide an
I guess it's wise to not ignore the "extra keywords" defined by the
driver, but shouldn't a custom dialect developer not be able to
override it? To me it sounds like you're shaping the correct decision
for the default dialect implementation, but ultimately I think people
should be able to know better, be it because their JDBC driver is
outdated or just because their RDBMs ignores the standards. Neither
seems too unlikely to happen in practice :)
On 1 May 2015 at 17:45, Steve Ebersole <steve(a)hibernate.org> wrote:
I understand what you are saying, in principle. Then there is the
side. Personally I am not so interested in doing all the investigation over
each Dialect to determine their exact set of keywords (A LOT of work), not
to mention typing all that up (A LOT of duplication). Of course, if someone
wants to volunteer to take on the task of identifying the exact set of
keywords for each Dialect I am not going to stop them. You volunteering? :)
As a compromise, we could have the complete set of keywords defined to
and have *our* Dialect impls incorporate the SQL:2003 keywords into what
If the driver is returning us "extra keywords", I think it is simply a
BadIdea(tm) to ignore that.
On Fri, May 1, 2015 at 9:26 AM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> Rather than basing our decisions on standards, wouldn't it be more
> useful to base it on *exactly* what the used database requires?
> In other words, why wouldn't it suffice to have a single source of
> keywords: the Dialect.
> On 1 May 2015 at 15:19, Steve Ebersole <steve(a)hibernate.org> wrote:
> > Interestingly, your IRC ping asked about KEY which in fact is *not* a
> > SQL:2003 keyword. It had been a keyword in 92 and 99 SQL standards, but
> > was removed in 2003.
> > Which actually opens up an another interesting discussion as far as how
> > aggressive to be in terms of affirming an identifier as being a keyword
> > and
> > thus quoting it. Do we use SQL:2003 as the baseline? Do we use SQL3
> > (99)? SQL2 (92)? Do we more aggressively build a superset from all 3?
> > My gut says we should:
> > 1) Use SQL:2003 as the baseline
> > 2) Augment with DatabaseMetaData#getSQLKeywords
> > 3) Augment with Dialect#getKeywords
> > 4) (?) Augment with application-provided keywords
> > FWIW (4) can actually be handles via custom PhysicalNamingStrategy in
> > terms
> > of a custom PhysicalNamingStrategy deciding to quote a given identifier.
> > On Fri, May 1, 2015 at 8:51 AM, Steve Ebersole <steve(a)hibernate.org>
> > wrote:
> >> Gail, I saw your ping on IRC and thought it made sense to address here,
> >> since you were not around on IRC anymore.
> >> Overall, starting with 5.0, the idea is for Hibernate to automatically
> >> quote any identifiers is recognizes as a keyword. This is all
> >> encapsulated
> >> within the org.hibernate.engine.jdbc.env.spi.IdentifierHelper obtained
> >> via
> >> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#getIdentifierHelper.
> >> There are 2 parts to this...
> >> First, we need to be able to recognize that an identifier is in fact a
> >> keyword. This piece is handled through
> >> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#isReservedWord, which
> >> is
> >> based on a Set of keywords computed from 2 distinct "keyword
> >> 1) Dialect#getKeywords
> >> 2) DatabaseMetaData#getSQLKeywords
> >> At the moment, I think this misses a third source... ANSI SQL 2003
> >> standard keywords. DatabaseMetaData#getSQLKeywords specifically is
> >> supposed to return only keywords beyond the standard (2003) defined
> >> ones.
> >> There are really 2 options to address this:
> >> 1) add these standard keywords to Dialect
> >> 2) use a seperate (static) source for them.
> >> Personally I prefer the second. Even if we added all the standard
> >> keywords to the base Dialect Set, it is just too easy for the Dialect
> >> subclass to override getKeywords(). Also, I like the idea of
> >> continuing
> >> the convention of these other 2 sources simply returning
> >> Second, and this is BY FAR the harder part, we need to make sure that
> >> everywhere that is building identifiers is using this code. I tried
> >> hard
> >> to make sure that was the case, but we all know that annotation binding
> >> is
> >> a mess and its just too easy to miss stuff in there. I'm all happy for
> >> a
> >> second (or third, or fourth, ...) pair of eyes looking over this part,
> >> but
> >> I personally think it is not the best allocation of our time
> >> considering
> >> the difficulty in actually finding them all just by code review and the
> >> time it would take and the amount of other stuff we have to do.
> >> Eventually
> >> we will get bug reports of cases where this does not happen. My $.02
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev