[hibernate-dev] Auto quoting of keywords used as identifiers

[Steve Ebersole]

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 at 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 sources":
> 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 "extras".
>
> 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
>