Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Alternative to ActiveRelationResource which does not produce extra DB queries

Open
  • Is something wrong?
#1,405 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
rails, ruby
Domain
database, performance

Research direction

Start by tracing ActiveRelationResource's uncached path for requests with include and compare it with the 0.9 and 0.10 query logs shown here. Done means an alternative or optimization avoids the extra relation and id queries without caching while preserving included records and pagination behavior.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Ruby
Stars
2.3k
Forks
546
No merged PRs in 30d

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from JSONAPI-Resources/jsonapi-resources

All issues in JSONAPI-Resources/jsonapi-resources

Similar issues

More Ruby issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.