Alternative to ActiveRelationResource which does not produce extra DB queries

[krasnoukhov]

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.

[lgebhardt]

I'm currently working on v0.11. One of the planned changes is to fetch the full models when caching is not used. This will be a slight change from how v0.9 worked.

I'm also looking at adding support for a backwards compatibility with 0.9 where the records_for_* methods are used. This won't be as efficient, but will hopefully allow us to stop maintaining the older releases.

[krasnoukhov]

Sounds promising @lgebhardt, thanks for the reply, appreciate it