Extend any() Behaviour to allow more than one Predicate

[mjungsbluth]

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.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[timowest]

Do you have some suggestions how this could be done syntactically?

[mjungsbluth]

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.

[azee]

+1

[ttyrueiwoqp]

+1

[ivorcosta]

+1

[soterocra]

+1

[priiduneemre]

+1

[guedes4g]

+1

[keith-miller]

Has anyone found a clean workaround for this?

[jwgmeligmeyling]

Question is if it can be supported at all, because Querydsl just renders the queries directly to JPQL, so it is the ORM that is responsible for generating the SQL.

All suggestions are fine, but we need to have something to shoot at. A working proof of concept in a PR.

[jwgmeligmeyling]

The workaround by the way is quite trivial: use a subquery ;-)

[keith-miller]

Thanks, will move to discussions then.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.