As far as I you desuce from the source code any() just uses a specific Path that later gets transformed during serialization. If you do something like
collectionProperty.any().prop1.eq("value1").and(collectionProperty.any().prop2.eq("value2")
This will result in two separate subqueries to be generated. I couldn't find any way to alias the any() in any way to achieve what I am after. Of course I can use a JpaSubQuery but its really verbose and ugly for these cases and I would rather prefer a simpler predicate.
In our use case Predicates which are parameterized with ParamS are used in the user interface to generate a filter panel that allows to fill in the params and sent a filled in Predicate to the backend which then execute(via a param replacing visitor). This looks highly elegant from a developer's perspective as its very easy to add new conditions that are relatively agnostic to how they will be executed.
The moment you have to use subquery definitions in the frontend things start looking a bit verbose and it just feels wrong to do this.
Do you have some suggestions how this could be done syntactically?
A)
alias = new QEntity("alias");
predicate = collectionProperty.any(alias, alias.prop1.eq().and(alias.eq()))
B)
alias = new QEntity("alias");
collectionProperty.any().as(alias)
alias.eq().and(alias....)
C) change the behaviour in CollectionAnyVisitor and collapse multiple any Paths in an expression sub tree (could be dangerous.
I'd prefer sth along the lines of A since this will be the most obvious to developers as it will pop up in code completion parallel to any(). In the respective visitor it would be straight foward to put the condition in the where clause of the subquery and use alias in the necessary join.
+1
+1
+1
+1
Most helpful comment
A)
alias = new QEntity("alias");
predicate = collectionProperty.any(alias, alias.prop1.eq().and(alias.eq()))
B)
alias = new QEntity("alias");
collectionProperty.any().as(alias)
alias.eq().and(alias....)
C) change the behaviour in CollectionAnyVisitor and collapse multiple any Paths in an expression sub tree (could be dangerous.
I'd prefer sth along the lines of A since this will be the most obvious to developers as it will pop up in code completion parallel to any(). In the respective visitor it would be straight foward to put the condition in the where clause of the subquery and use alias in the necessary join.