-
Notifications
You must be signed in to change notification settings - Fork 619
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
Add default_versions
database table
#8484
Conversation
2bb28d0
to
772edb9
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8484 +/- ##
==========================================
- Coverage 88.44% 88.33% -0.12%
==========================================
Files 270 274 +4
Lines 26899 27106 +207
==========================================
+ Hits 23792 23943 +151
- Misses 3107 3163 +56 ☔ View full report in Codecov by Sentry. |
772edb9
to
af423fc
Compare
…re deleted This ensures that we don't end up in a situation where we have deleted the default version from the `versions` table, but it's still referenced from the `default_versions` table.
af423fc
to
fef072e
Compare
This PR adds a new database table:
default_versions
. This table has only two columns:crate_id
andversion_id
.Once the table has been filled with the
update-default-versions
admin command it will contain a row for every crate in the database, pointing to the version that will be shown by default by the front-end (not implemented yet) and can be used for other queries where useful (e.g. reverse dependencies).This calculation has to be performed on the Rust side, since it involves sorting by SemVer and the Postgres extension for SemVer is unfortunately not available on Heroku.
There are four different operations to consider to keep this table in sync:
version_id
straight into the database since this is the first and therefore default version.Note that the code currently does not prevent the
update_default_version()
fn from running multiple times in parallel for the same crate. I'm open to implementing such a lock, I just haven't found a good way to do it yet. It currently does not deduplicate the background jobs either, but since the job is quite fast it is most likely not needed anyway.Note also that this table is currently write-only and not used anywhere yet. Once we have had this running in production for a few days we can check whether we see any inconsistencies before we use the data anywhere.