-
Notifications
You must be signed in to change notification settings - Fork 21.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #first(limit) to take advantage of #loaded? records if available #22053
Conversation
r? @chancancode (@rails-bot has picked a reviewer for you, use r? to override) |
first(limit)
to take advantage of loaded?
records if available
@chancancode Thoughts on this? |
topics = Topic.all.order('id ASC') | ||
|
||
assert_queries(1) do | ||
topics.to_a # force load |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could move this outside the assert_queries
block. Then we don't have to do the actual code 2 times and we can assert that no queries are executed.
All uses of the `offset` are passing `offset_index`. Better to push down the `offset` consideration into `find_nth`. This also works toward enabling `find_nth_with_limit` to take advantage of the `loaded?` state of the relation.
I realized that `first(2)`, etc. was unnecessarily querying for the records when they were already preloaded. This was because `find_nth_with_limit` can not know which `@records` to return because it conflates the `offset` and `index` into a single variable, while the `@records` only needs the `index` itself to select the proper record. Because `find_nth` and `find_nth_with_limit` are public methods, I instead introduced a private method `find_nth_with_limit_and_offset` which is called internally and handles the `loaded?` checking. Once the `offset` argument is removed from `find_nth`, `find_nth_with_limit_and_offset` can be collapsed into `find_nth_with_limit`, with `offset` always equal to `offset_index`.
@senny Made the changes you suggested - note 2 questions:
|
@Empact It's not necessary to make a PR for the removal. Once we release a new Major or Minor version we go through all deprecations and remove the ones that are due. Usually they stay for one release cycle. Meaning that the option will be deprecated in 5.0 and will be removed from 5.1. |
Fix #first(limit) to take advantage of #loaded? records if available
Thanks @senny! 🎆 |
I realized that
first(2)
, etc. were unnecessarily querying for therecords when they were already preloaded. This was because
find_nth_with_limit
can not know which@records
to return becauseit conflates the
offset
andindex
into a single variable, whilethe
@records
only needs theindex
itself to select the properrecord.
Because
find_nth
andfind_nth_with_limit
are public methods, Iinstead introduced a private method
find_nth_with_limit_and_offset
which is called internally and handles the
loaded?
checking.Once the
offset
argument is removed fromfind_nth
,find_nth_with_limit_and_offset
can be collapsed intofind_nth_with_limit
, withoffset
always equal tooffset_index
.