[hibernate-dev] 6.0 - HQL literals

Christian Beikov christian.beikov at gmail.com
Wed Jan 8 08:09:54 EST 2020


Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     If a user enters a HQL literal, that user wants the literal to be
>     rendered like that if possible(which should always be possible).
>
>
> Like I said earlier, we actually try to render literals (of any type) 
> as parameters whenever we can (which is almost always possible)

IMO this should be configurable and I personally would prefer rendering 
as SQL literal as I'd argue people would generally only use a literal if 
they really want a literal i.e. not append a literal in a dynamic way 
like `"FROM Entity e WHERE e.active = " + someBoolean`. Such a query 
might be better off with a parameter. Why do you prefer rendering 
literals as parameter?

Most DBMS can better optimize a query plan when encountering literals 
vs. parameters e.g. choose a partial index or have better estimates. The 
trade-off is performance for possibly "worse" statement cache hit rate. 
I'd argue people would just use parameters if they want possible 
statement sharing or better caching.

>
>
>     The only thing we have to define is whether the literal is by
>     default in
>     the JVM TZ, JDBC TZ or UTC. We could offer syntax variants that
>     default
>     to UTC etc.
>
>
>     Not sure what makes sense, even if I like UTC more, to me it feels
>     like
>     the default should be using the JDBC TZ(which by default is the
>     JVM TZ)
>     and offer a dedicated literal syntax for the UTC variant as well as
>     support for specifying the TZ explicitly.
>
>
> The literal can define the zone if they want control.  I think that is 
> enough. Conceptually that is what "JDBC time zone" is supposed to mean 
> exactly what we are discussing here, right?
>
Right


More information about the hibernate-dev mailing list