database_dump: Fix num_no_build import issue

[Turbo87]

The num_no_build column in the database is NOT NULL, but since we don't export it in the database dump it will show up as an empty value and thus fail to get imported correctly. This commit temporarily drops the NOT NULL constraint during the data import, backfills the data from the num column, and then adds the constraint again.

Related:

• database: Change num_no_build to be NOT NULL #9767 (comment)
• Exclude num_no_build from versions.csv db-dump #9786

[Turbo87]

This seems to fix the issue, but now that I've written the code I'm questioning the brittleness of this approach vs. reverting #9786.

because in downstream code it's trivial to reconstruct from the value of num if needed.

unfortunately, we have 797 versions where it is not trivial, because we have duplications in there. fixing these duplications is possible (see this PR or #9767 (comment)), but 1) does it result in the same data as in the production database? and 2) is it worth the brittleness?

I think I'm leaning towards reverting #9786 instead, but I'm open to other opinions.

/cc @rust-lang/crates-io @dtolnay

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.47%. Comparing base (a27a914) to head (b71d9d4).
Report is 24 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #10097   +/-   ##
=======================================
  Coverage   89.47%   89.47%           
=======================================
  Files         294      294           
  Lines       31254    31254           
=======================================
+ Hits        27964    27965    +1     
+ Misses       3290     3289    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[LawnGnome]

I think I'm leaning towards reverting #9786 instead, but I'm open to other opinions.

I'd also rather do a revert, I think.

[eth3lbert]

I think I'm leaning towards reverting #9786 instead, but I'm open to other opinions.

Yeah, maybe reverting is a better choice, which would also eliminate the need for potential future maintenance.

[Turbo87]

we talked through this in the crates.io team meeting today and concluded to revert #9786 instead.