Alternative to ActiveRelationResource which does not produce extra DB queries

Bắt đầu bằng cách theo dõi đường dẫn không được cache của ActiveRelationResource đối với các request có include và so sánh với các query log của 0.9 và 0.10 được hiển thị ở đây. Công việc được xem là hoàn tất khi một phương án thay thế hoặc tối ưu hóa tránh được các query bổ sung về relation và id mà không caching, đồng thời vẫn giữ nguyên các record được include và hành vi phân trang.

This issue is a (choose one):

• Problem/bug report.
• Feature request.
• Request for support. Note: Please try to avoid submitting issues for support requests. Use Gitter instead.

Checklist before submitting:

• I've searched for an existing issue.
• I've asked my question on Gitter and have not received a satisfactory answer.
• I've included a complete bug report template. This step helps us and allows us to see the bug without trying to reproduce the problem from your description. It helps you because you will frequently detect if it's a problem specific to your project.
• The feature I'm asking for is compliant with the JSON:API spec.

Description

One thing that changed significantly in 0.10 is the introduction of ActiveRelationResource, which seems to be a nice optimization to have when caching is utilized. But when caching is not turned on it actually doubles the amount of DB queries needed to process a request. For example, typical request with include would look something like this in the log on 0.10.x:

DEBUG -- :    (0.0ms)  SELECT "users"."id" AS "users_id", "users"."id" FROM "users" ORDER BY users.id asc LIMIT ? OFFSET ?  [["LIMIT", 10], ["OFFSET", 0]]
DEBUG -- :    (0.1ms)  SELECT DISTINCT users.id AS "source_id", "profiles"."id" AS "profiles_id", "profiles"."id" FROM "users" INNER JOIN "profiles" ON "profiles"."user_id" = "users"."id" WHERE "users"."id" IN (?, ?, ?) ORDER BY profiles.id asc  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :    (0.0ms)  SELECT DISTINCT users.id AS "source_id", "posts"."id" AS "posts_id", "posts"."id" FROM "users" INNER JOIN "posts" ON "posts"."user_id" = "users"."id" WHERE "users"."id" IN (?, ?, ?) ORDER BY posts.id asc  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :   User Load (0.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (?, ?, ?)  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :   Profile Load (0.0ms)  SELECT "profiles".* FROM "profiles" WHERE "profiles"."id" IN (?, ?, ?)  [["id", 1], ["id", 2], ["id", 3]]
DEBUG -- :   Post Load (0.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" IN (?, ?, ?, ?, ?, ?, ?, ?, ?)  [["id", 1], ["id", 2], ["id", 3], ["id", 4], ["id", 5], ["id", 6], ["id", 7], ["id", 8], ["id", 9]]
DEBUG -- :    (0.0ms)  SELECT COUNT(*) FROM "users"

Compare to the same request on 0.9:

DEBUG -- :   User Load (0.0ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ? OFFSET ?  [["LIMIT", 10], ["OFFSET", 0]]
DEBUG -- :   Profile Load (0.1ms)  SELECT "profiles".* FROM "profiles" WHERE "profiles"."user_id" IN (?, ?, ?)  [["user_id", 1], ["user_id", 2], ["user_id", 3]]
DEBUG -- :   Post Load (0.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."user_id" IN (?, ?, ?)  [["user_id", 1], ["user_id", 2], ["user_id", 3]]
DEBUG -- :    (0.0ms)  SELECT COUNT(*) FROM "users"

Is there a plan to optimize non-cached scenario? Like having an alternative base resource that I'd behave more or less like 0.9 behaved? Thanks.