Clauses involving one-to-many relations in a filter require separate jointures or a subqueries #708
Milestone
Comments
|
I'm starting to lean more in favour of subqueries for this. It will ease the Criteria-based filtering service implementation since it already natively supports this via a SubqueryExpression. For HQL, unfortunately it will not be easy, but there should be enough information in the property meta to generate the jointure necessary in the subquery. The upside is that by doing this, we will not require the group by clause anymore nor distinct for counting, so there might be a noticeable performance gain. |
If more information is needed, we might have to make the content of FilteringQueryUtils protected in AbstractQueryFilteringDao so that it can access metadata. |
This was
linked to
pull requests
Jun 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
They currently result in contradictions where clauses such as:
c.id = 1 and c.id= 2are generated.This could be resolved in two different ways:
Multiple jointures (one per clause)
join c as c1 join c as c2 where c1.id = 1 and c2.id = 2The disadvantage is that we do not control the process that produces the jointures when generating the restriction clause, so it will require significant changes.
Subqueries
where id in (select id from Entity e join e.c where e.c.id = 1) and id in (...)Advantage: clauses are contained and likely easier to generate.
Drawback: the context to refer to aliases in the root query is not available.
The text was updated successfully, but these errors were encountered: