Replies: 1 comment 3 replies
-
This is how SQL works, it's called a cartesian product. And because of this, the ORM employs a pagination mechanism - that's the subquery matching based on the PK you see in this example, since you can't just limit stuff that produces the cartesian product, you want to limit the root entities only. If you want to get around this, you can't use joins (or better say joins on to-many relations) - the alternative select-in strategy is here for exactly that case, it will use a query per type instead of joins (the joins will be still used for the where condition but not for the selects). Do you have an actual issue or it's just you discovered how SQL joins work and you don't like that? :] |
Beta Was this translation helpful? Give feedback.
-
Hi,
Using the now default
joined
strategy, the defaultpopulateWhere: "all"
, and the following example entities:And after calling a
findAll
on theAuthor
repository for example:It constructs the following query (formatted for some legibility):
Which returns the expected result when processed by the ORM. But if I am not wrong, if there are 10 authors, and each author has 20 books for example, then that query is returning 4000 rows, which could be a lot bigger if the number of books by author increases and it could generate a meaningful performance hit.
Am I doing something wrong? or is there a reason that it couldn't be done another way?
Beta Was this translation helpful? Give feedback.
All reactions