-
-
Notifications
You must be signed in to change notification settings - Fork 134
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
Unavoidable Rank N+1 Queries #196
Comments
Hi @CodingAnarchy, can you give a quick example? I'm not too familiar with that SQL so an example would be helpful :D |
I'm not sure what kind of example would be most helpful here, but now that I am considering it more, I know that window functions are not supported by some common older MySQL versions (I think they added it in 8.0). I believe Postgresql has had the concept since version 11. So this might be a touch premature, as we will need these older versions to go EOL and be phased out by most users to avoid hacky workarounds. On the subject of window functions as a whole, the linked documentation might help familiarize the concept, though. |
Thanks @CodingAnarchy, let's leave this here for posterity :) |
Closing this for now. Have a look at my new positioning gem. If you ever end up using it, I'd be interested in seeing if we could implement support for the there :) |
Currently it is impossible to avoid N+1 queries over a partitioned rank ordering. The following ranking, for instance, does not enable querying with a pre-populated rank value:
SQL allows for queries that could pre-populate this value, though. We could do something like:
I believe a
PARTITION BY
statement could be supplied for each possibility of complex ranking (for simple ranking, it is unnecessary), but I haven't looked into it completely.The text was updated successfully, but these errors were encountered: