jakartaee / persistence

https://jakartaee.github.io/persistence/
Other
189 stars 55 forks source link

JPQL native syntax for date/time literals #453

Open gavinking opened 11 months ago

gavinking commented 11 months ago

This came up in #391.

Currently, JPQL has no native syntax for date/time literals, and just piggy-backs off the JDBC escape syntax. This syntax is kinda ugly and looks visually out-of-place in a JPQL query.

We recently added a native syntax for this to HQL, it's documented here:

https://docs.jboss.org/hibernate/orm/6.3/querylanguage/html_single/Hibernate_Query_Language.html#datetime-literals

I think it would be nice to add some subset of this to the spec.

Thoughts?

trajano commented 11 months ago

Braced primarily because it is shortest among them. Not only that you can tell when it ends unlike the third one. Question is how do we handle ZonedDateTime and Instant but it may be implicit with OffsetDateTime already.

The thing you need to make sure of is the capability of passing it with a Z timezone. The other thing to watch out for is the MIN and MAX values for Instant and ZonedDateTime are different.

gavinking commented 11 months ago

Braced primarily because it is shortest among them.

It's short, but it's also the option that looks most out of place in the SQL-like syntax. I personally don't find it aesthetically appealing, though of course others are free to disagree.

Not only that you can tell when it ends unlike the third one.

This is an advantage indeed.

gavinking commented 11 months ago

Question is how do we handle ZonedDateTime and Instant but it may be implicit with OffsetDateTime already.

I don't think we actually need Instant literals, all you would need is an implicit conversion from OffsetDateTime to Instant.

That said, I do still think that having the type stated explicitly, as in date 2000-12-3 is a weak advantage.

trajano commented 11 months ago

The closest thing to SQL is literally '

That is '2023-08-14' and having the JPQL know that the target the type LocalDate and perform the necessary. However, I still prefer { } because it opens up the possibility of other things lets say

gavinking commented 11 months ago

Right, this is an argument that @sebersole also makes.

trajano commented 11 months ago

Which one @gavinking the use of ' or the additional representations possible

gavinking commented 11 months ago

Your point about { .... } being generalizable to other types.