Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@notmarkmiranda Can you take a look at this? Believe it reduces the number of queries run in this method.
Summary
Believe this change reduces the number of queries used to get eligible projects without a vote from a user. Takes advantage of the
voted_projects
relationship on User.Details
Previously we had this:
Which results in two queries (one when we set
projects
, and the other beginning withwhere
on the third line.Updated to the following:
Finding the user and then finding that user's voted projects (rather than finding a value on the join given the
user_id
) seems to more directly reflect what this query is trying to do.Thought this would still run two queries, but when I run
#to_sql
on that method it results in a single query with a subquery in it to find the voted projects. That feels like a win to me. Can you confirm?Questions
Believe we sacrifice some legibility here for fewer queries. Is it worth it?
I'm frustrated that the following doesn't work, and can't spot what I'm missing. Tried this with a
.find
in place of the.where
as well:Might not chase this too much if the updated query in the current PR results in a single query.