persistence
persistence copied to clipboard
JPQL native syntax for date/time literals
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:
I think it would be nice to add some subset of this to the spec.
Thoughts?
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.
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.
Question is how do we handle
ZonedDateTimeandInstantbut it may be implicit withOffsetDateTimealready.
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.
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
UUID- semantic versions {2.0.5} // I don't think any database supports that
- geo data such as {-77.00, 55.00} representing latitude and longitude
- A period
{ 2023-08-14 to 2023-08-30 } - A duration
{ 16 days }
Right, this is an argument that @sebersole also makes.
Which one @gavinking the use of ' or the additional representations possible
Your point about { .... } being generalizable to other types.