feat: implement separate fetch relations in findOptions

[GaryXiongxiong]

This new feature allow fetch relations in separated sql query, that will fix memory running out when .find() called with multiple join relations. This issue is described in #5829 & #3857

Fixes: #5829

Description of change

This new feature allow fetch relations in separated sql query, that will fix memory running out when .find() called with multiple join relations. This issue is described in #5829 & #3857

You can fetch relations by using:

    const posts = await connection.manager.find(Post, {
        relations: ["category"],
        where: {category:{name: "Category #2"}},
        separateFetchRelations: ["author","author.post"]
    });

Then the relation author and post of author will be queried in separated sql:

SELECT * FROM post 
LEFT JOIN category on category.post_id = post.id
WHERE category.name = 'Category #2';

SELECT * FROM author
WHERE author.post_id = post_id; --post's id just fetched

SELECT * FROM post
WHERE post.author_id = author_id; --author's id just fetched

Pull-Request Checklist

• Code is up-to-date with the master branch
• npm run lint passes with this change
• npm run test passes with this change
• This pull request links relevant issues as Fixes #0000
• There are new or updated unit tests validating the change
• Documentation has been updated to reflect this change
• The new commits follow conventions explained in CONTRIBUTING.md

[pleerock]

Functionality of separate queries for relations were implemented in @next branch years ago. Unfortunately we were not able to release them in time, and now @next is far away behind master in many aspects.

I think current implementation of this feature in @next is more advanced and we should port changes from there to master.

But the way it was implemented in @next is simply replacing of current join approach completely to separate queries. Some people were disagree, because in some cases joins are more effective. But mostly I think it's a better approach.

So, what if we port what we have in @next, keep what we have in master and introduce a new option called relationLoadStrategy: "join" | "query" ?

@GaryXiongxiong do you want to spend more of your time / will in order to check how it's currently implemented in @next and think how to properly port it to master?

[YixiongJiang]

Functionality of separate queries for relations were implemented in @next branch years ago. Unfortunately we were not able to release them in time, and now @next is far away behind master in many aspects.

I think current implementation of this feature in @next is more advanced and we should port changes from there to master.

But the way it was implemented in @next is simply replacing of current join approach completely to separate queries. Some people were disagree, because it some cases joins are more effective. But mostly I think it's a better approach.

So, what if we port what we have in @next, keep what we have in master and introduce a new option called relationLoadStrategy: "join" | "query" ?

@GaryXiongxiong do you want to spend more of your time / will in order to check how it's currently implemented in @next and think how to properly port it to master?

Yeah, will take some time for it

[GeiOoo]

I dont wanna rush... but is there any progress on that topic?
We've got some huge performance problems with fairly complex entity relations.
A fully resolved query for a single record can easily result in a 75000 row result set taking about 2 seconds to execute.
We would love to spread those LEFT JOIN in separate queries to minimize data flow.

[Penners]

Feature looks great! Looking forward to when it gets merged.

[pleerock]

implemented in #8616