You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So in rust-lang#592, I accidentally changed the meaning of the
`reverse_dependencies` query from "select 10 crates where the max
version of that crate depends on this one" to "select 10 crates where
that crate had a version with the same number as this one's max version,
which depended on this crate" which is nonsense and wrong.
There's actually no way that we can truly replicate the old behavior
without breaking pagination or loading all the versions of every crate
which has ever depended on another into memory and doing the limiting
locally... which would defeat the purpose of pagination.
The only real alternative here is to revert rust-lang#592 and go back to updating
the `max_version` column. I still think this approach is the right one,
even with the added complexity to this column, as updating `max_version`
will always be bug-prone unless we can do it in SQL itself. It's too bad
we can't enable arbitrary extensions on heroku PG, as we could actually
create a true semver type that links to the rust crate if we could.
The main difference in behavior between this and the `max_version`
column is that if a crate had *only* prerelease versions, and only some
of those prerelease versions depended on another crate, it's effectively
random whether it would appear in this list or not. It's a very niche
edge case and one that I'm not terribly concerned about.
I'd need to play around with indexes to see if this query could be
optimized further, but the performance should be reasonable, as the
window function will only require a single table scan.
Fixesrust-lang#602.
0 commit comments