Am 08.01.2020 um 20:21 schrieb Steve Ebersole:
> On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov
> mailto:christian.bei...@gmail.com>> wrote:
>
>
> This is about JPA Criteria whereas I was referring to how a
> literal in
> HQL ends up in the SQL. I agree that with JPA Criteria things
On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov
wrote:
>
> This is about JPA Criteria whereas I was referring to how a literal in
> HQL ends up in the SQL. I agree that with JPA Criteria things are
> different as the API for parameters in queries is not very neat. A flag
> for controlling how
Am 08.01.2020 um 14:47 schrieb Steve Ebersole:
> On Wed, Jan 8, 2020 at 7:11 AM Christian Beikov
> mailto:christian.bei...@gmail.com>> wrote:
>
> Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
> > mailto:christian.bei...@gmail.com>
>
On Wed, Jan 8, 2020 at 7:11 AM Christian Beikov
wrote:
> Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
> > mailto:christian.bei...@gmail.com>> wrote:
> >
> > If a user enters a HQL literal, that user wants the literal to be
> >
Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
> 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
On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
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
Actually Java and JDBC say that all of these Java 8 temporal types are
valid to pass via JDBC. It's done "implicitly" via the various
`#setObject` methods (as opposed to `#setTimestamp` e.g.).
Part of the problem here (6 and before) at the moment is that our
LocalDateTimeType, ZonedDateTimeType,
On Wed, Jan 8, 2020 at 4:21 AM Yoann Rodiere wrote:
> > This does nothing with Type. The way the grammar is defined it
> literally understands each piece of the temporal. So given, e.g.,
> {2020-01-01}, we know that 2020 is the year, etc. This is the benefit of
> defining it syntactically.
>
If a user enters a HQL literal, that user wants the literal to be
rendered like that if possible(which should always be possible).
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
> Can't we just render a literal in the DBMS proprietary way as literal
again
> but with respective TZ information to avoid TZ issues in the JDBC driver?
This may be an option. We would need to take into account the default JVM
timezone, or the "jdbc_timezone" setting, to set the correct offset.
Can't we just render a literal in the DBMS proprietary way as literal again
but with respective TZ information to avoid TZ issues in the JDBC driver?
If we use an instant literal we use the UTC TZ in a SQL literal or function
to render that.
Yoann Rodiere schrieb am Mi., 8. Jän. 2020, 11:22:
>
> This does nothing with Type. The way the grammar is defined it literally
understands each piece of the temporal. So given, e.g., {2020-01-01}, we
know that 2020 is the year, etc. This is the benefit of defining it
syntactically.
I trust you can build a temporal correctly from a string. I'm
12 matches
Mail list logo
