accept value() or element() in place of elements() and key() or index() in place of indices()
Description
Activity

Gavin King May 30, 2023 at 1:24 PM
Conclusion: I did not make the suggested change discussed above, but I did a lot of work to explain this stuff in the documentation, and I hope it’s now clear.
I also, for consistency, let you write keys()
and values()
which it’s a Map
.
This issue can be closed.

Gavin King May 30, 2023 at 10:45 AM
Christian that’s a good question, but I don’t particularly see why not.
And I think the boat already sailed as far as these functions only applying to identification variables. We’ve been allowing implicit joins on collections in 6 for quite a while now, even though we never explicitly decided to do so.
And frankly I’m OK with that.

Christian Beikov May 30, 2023 at 10:31 AM
AFAIK the JPA “functions” key
/index
and value
are supposed to be only allowed on join aliases.

Christian Beikov May 30, 2023 at 10:30 AM
Should the first case even be allowed? I thought plural paths are only allowed in very specific syntax constructs to avoid altering cardinality through implicit joins.

Gavin King May 30, 2023 at 8:39 AM
OK, so actually we can’t do this because of the following case:
vs:
These actually have different interpretations in HQL today.
(The first is an implicit join, the second is an implicit subquery.)
But even so, this has led me to some useful cleanups and clarifications.
Writing the docs, I still struggle to explain the role of the
elements()
andindices()
functions, and I think they’re still quite confusing.So what if we finally deprecated them and let you just use
element()
,value()
,index()
, andkey()
instead?That is, we would accept:
max(element(experiment.measurements))
,max(index(record.revisions))
0.0 < every element(experiment.measurements)
,1 = any index(record.revisions)
1 in index(record.revisions)
,"hibernate" in element(document.tags)
exists(element(experiment.measurements))
In cases 1 and 4, the revised syntax reads significantly better.
In case 2, the revised syntax reads better if you use the
every
/any
form of the quantifiers, or worse if you use theall
/some
version.In case 3, the revised syntax reads definitely worse. But how useful is
in
with collections when we also have:member of
, andthe option of writing
1 = any index(record.revisions)
.Or perhaps we could just make
elements
a synonym forelement
andindices
a synonym forindex
and let you write whatever you like.Thoughts?