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

[Steve Ebersole]

I understand what you are saying, in principle.  Then there is the
practical 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
combination of:
1) DatabaseMetaData#getSQLKeywords
2) Dialect#getKeywords

and have *our* Dialect impls incorporate the SQL:2003 keywords into what
they return.

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 at 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.
>
> --Sanne
>
>
>
> On 1 May 2015 at 15:19, Steve Ebersole <steve at 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 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
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>