[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