> 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 mo
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:
>
> 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.
H
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 su
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.
>
>
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 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 (whi
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 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
> > rendered
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 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 lit
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 a
12 matches
Mail list logo
