Am 08.01.2020 um 13:50 schrieb Steve Ebersole: > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev