Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
<christian.beikov(a)gmail.com <mailto:christian.beikov@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