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

Description

Writing the docs, I still struggle to explain the role of the elements() and indices() functions, and I think they’re still quite confusing.

So what if we finally deprecated them and let you just use element(), value(), index(), and key() instead?

That is, we would accept:

  1. max(element(experiment.measurements)), max(index(record.revisions))

  2. 0.0 < every element(experiment.measurements), 1 = any index(record.revisions)

  3. 1 in index(record.revisions), "hibernate" in element(document.tags)

  4. 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 the all/ some version.

In case 3, the revised syntax reads definitely worse. But how useful is in with collections when we also have:

  • member of , and

  • the option of writing 1 = any index(record.revisions).

Or perhaps we could just make elements a synonym for element and indices a synonym for index and let you write whatever you like.

 

Thoughts?

Activity

Show:

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.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Created May 29, 2023 at 7:44 PM
Updated July 20, 2023 at 6:48 PM
Resolved May 31, 2023 at 10:36 AM