-
Notifications
You must be signed in to change notification settings - Fork 54
fix(GH-220): Cannot nest multiple queries on the same table #222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(GH-220): Cannot nest multiple queries on the same table #222
Conversation
Codecov Report
@@ Coverage Diff @@
## master #222 +/- ##
============================================
- Coverage 73.69% 73.54% -0.15%
+ Complexity 850 846 -4
============================================
Files 49 49
Lines 3668 3651 -17
Branches 613 606 -7
============================================
- Hits 2703 2685 -18
- Misses 700 703 +3
+ Partials 265 263 -2
Continue to review full report at Codecov.
|
@molexx I have fixed the problem with nested multiple queries in where criterias. In the process, I have realized that regular root where expressions were adding extra joins instead of reusing existing fetch joins from the selection graph. I have fixed that and also enabled So, to summarize, all where root criteria expressions will now apply restrictions on the fetch joins. It will make results of the query filtered using joins. Count queries with apply restrictions on regular joins instead of fetch join for better performance. There is expanded support to use As I mentioned in the issue, the many-to-many relationship with circular dependencies do not work correctly. I have added |
Thanks! I think that makes sense to have EXISTS. I'll pull this into my tree - along with graphql-13 and executor-context-factory. Is the outstanding issue the one where Luke is appearing despite not being friends with himself? I think that is due to outer joins, I have made a comment on the issue. |
I cannot seem to find any solution to fix it with or without optional query modifier. Maybe you could see what is going on?
JPQL Query Fetch Joins are inner
Result:
|
@igdianov can you see my latest comment on the issue please? Executing the query myself it looks ok, the correct data is returned - 5 rows, 3 for C3PO and 2 for R2 - and Luke isn't listed as one of R2's friends yet appears in the graphql response, where is he coming from? |
ab829b1
to
9e0fce9
Compare
9e0fce9
to
24891c1
Compare
This PR fixes the query and mapping problem with nested recursive queries in where search criterias with
@ManyToMany
mapping on Character entity.For example, when mapping "author" / "book" as many-to-many, we need "authors" collection on Book and "books" collection on Author. In our case, "Character" entity represents both ends of a relationship; so we need "friends to" and "friend of" collections.
We can still use the same association table, but note that friendsOf is mappedBy
friends
.The "friends" and "friendsOf" collections may or may not match (depending on whether "friendship" is mutual or not).
After fixing the relationship, the following query returns correct result:
Generated JPQL:
Result:
In the process, I have realized that regular root where expressions were adding extra joins instead of reusing existing fetch joins from the selection graph. I have fixed that and also enabled EXISTS predicate expressions on all relations to provide support for the previous behavior using subsquery expressions, i.e.
with WHERE
With WHERE EXISTS
It also fixes the problem with double wrapping of plural attribute types in GraphQL list type.
So, to summarize, all where root criteria expressions will now apply restrictions on the fetch joins. It will make results of the query filtered using joins and filter results in collections.
Count queries with apply restrictions on regular joins instead of fetch join for better performance.
There is expanded support to use EXISTS subquery for all relationship types to bridge for the old where criteria expressions. You can see changes in the tests
Fixes #220