Remove yanked versions from reverse_dependencies#1104
Conversation
|
I just realized after posting this that this may need to go into the v2 API only since it's altering behavior people may have been relying on. Will fix accordingly tomorrow. |
|
@sferik Merged master to account for your merging of my other recent PRs. Curious what you think as well. |
|
@olivierlacan I’d prefer you rebase from master and force push, so there’s no merge commit. |
|
@olivierlacan After you do that, I’m 👍 overall. |
|
I’m not worried about breaking API v1. Nobody should be relying on this behavior. |
|
Awesome job 🚀 |
olivierlacan
force-pushed
the
exclude-yanked-gems-from-reverse-deps
branch
from
dd5b894 to
d0b5280
Compare
There was a problem hiding this comment.
@olivierlacan It's not a big deal but I think "except yanked versions" doesn't need parenthesis.
This is something I remember surprising me when reading @schneems' http://www.schneems.com/blogs/2015-09-30-reverse-rubygems/. Why did he need to rescue while querying the API for gems depending on the gem he was searching for? I got my answer when I tried to run reverse dependencies for rake and hundreds of exceptions popped up for gems that have been yanked altogether, not sure why. Skipping yanked versions will probably speed up this endpoint a bunch although it's hard for me to test at this point. I can just log for posterity that before this commit the following requests total response times were as follows: - https://rubygems.org/api/v1/gems/rake/reverse_dependencies.json => 4.21 s (X-Runtime: 1.649987) - https://rubygems.org/api/v1/gems/rails/reverse_dependencies.json => 2.82 s (X-Runtime: 0.522366) - https://rubygems.org/api/v1/gems/bundler/reverse_dependencies.json => 3.89 s (X-Runtime: 1.636216) - https://rubygems.org/api/v1/gems/rack/reverse_dependencies.json => 1.97 s (X-Runtime: 0.188214)
olivierlacan
force-pushed
the
exclude-yanked-gems-from-reverse-deps
branch
from
d0b5280 to
2e105ee
Compare
|
Thanks to the handy data dumps, I've now tested this locally and it works great. Not a single API error when fetching all listed reverse_dependencies for The gem count goes from 2577 to 2454 gems for |
…everse-deps Remove yanked versions from reverse_dependencies
|
Nice! |
|
Deployed. 🚀 |
|
Yay! Thanks Erik!
|
4 participants
This is something I remember surprising me when reading @schneems' http://www.schneems.com/blogs/2015-09-30-reverse-rubygems/.
Why did he need to rescue while querying the API for gems depending on the gem he was searching for?
I got my answer when I tried to run reverse dependencies for rake and hundreds of exceptions popped up for gems that have been yanked altogether, I'm not sure why.
Skipping yanked versions will probably speed up this endpoint a bunch although it's hard for me to test at this point. I can just log for posterity that before this commit the following requests total response times were as follows:
Please do let me know if I'm completely out of my depths here, since I don't know much more about version yanking as what I could gather from going through the
VersionandDeletioncode. I still don't understand what causes a gem to be removed from the index entirely but I'm guessing that's when all its versions are yanked? /cc @qrush