specify key(), value(), entry() #82
Conversation
|
|
||
| The argument of the `#key()#`, `#value()#`, or #entry()# function must be an alias of a collection join of a <<collections,map>>, as defined in <<join-clauses>>. | ||
|
|
||
| **TODO** This is very restrictive. Should we allow application of `#key()#` or `#value()#` to a path expression? |
There was a problem hiding this comment.
While the simplified syntax
SELECT key(e.map) FROM Entity e
For Jakarta Query 1.0, we agreed to retain the current rule consistent with historical JPQL semantics:
key(), value(), and entry() apply only to collection join aliases, as in:
SELECT key(p) FROM Entity e JOIN e.map p
We may revisit implicit path-based key()/value() resolution in a later revision (e.g., 1.1) once we can define precise semantics for implicit joins and typing.
There was a problem hiding this comment.
Not sure what you're saying here, @otaviojava.
For Jakarta Query 1.0, we agreed to retain the current rule consistent with historical JPQL semantics:
We did?
Do you mean Jakarta Data 1.0, maybe?
once we can define precise semantics for implicit joins and typing.
"Implicit joins" already have well-defined semantics in Jakarta Query, since they are a long-standing feature of JPQL.
There was a problem hiding this comment.
We did?
I remember that we had this concern about break compability.
"Implicit joins" already have well-defined semantics in Jakarta Query, since they are a long-standing feature of JPQL.
Hum, in that case, I would say yes.
3 participants
See #65.