Depends on #282 (note: for convenience, it's not a stacked PR, but it should not be merged before #282 is, otherwise lots of things will break)
As the title says, this removes the default value on the non-nullable tenant_id columns in relevant tables. This does not affect existing rows, which got the default value 0 written explicitly when the column was added; it only affects the behavior of new insertions, which now require tenant_id to be specified explicitly. An insert lacking that column will fail.
The main reason to do this is to make it more difficult to accidentally introduce regressions where we insert something without a tenant_id and it defaults to 0 (which would be fine for now in ARPA but be bad in a future combined GOST/ARPA world where there are actually multiple tenants).
I think all existing places that do inserts (including seeds) were updated in #282, but it might be prudent to do some additional manual testing against this migration locally and/or in staging. Breakages should be pretty easy to spot: operations that insert new rows will throw exceptions if they haven't been updated properly.
Depends on #282 (note: for convenience, it's not a stacked PR, but it should not be merged before #282 is, otherwise lots of things will break)
As the title says, this removes the default value on the non-nullable
tenant_idcolumns in relevant tables. This does not affect existing rows, which got the default value0written explicitly when the column was added; it only affects the behavior of new insertions, which now requiretenant_idto be specified explicitly. An insert lacking that column will fail.The main reason to do this is to make it more difficult to accidentally introduce regressions where we insert something without a
tenant_idand it defaults to 0 (which would be fine for now in ARPA but be bad in a future combined GOST/ARPA world where there are actually multiple tenants).I think all existing places that do inserts (including seeds) were updated in #282, but it might be prudent to do some additional manual testing against this migration locally and/or in staging. Breakages should be pretty easy to spot: operations that insert new rows will throw exceptions if they haven't been updated properly.