Cleanup migrations introduced before 2019
What does this MR do?
This cleans up and removes database migrations from before 2019. The effect of those is being squashed into the 20181228175414_init_schema
migration. This version number is the maximum version from migrations introduced in 2018 and we're now reusing it to provide the full initial schema.
We can do this because we require GitLab major upgrades to go from one major to the next major version at a time. Migrations introduced in 2018 have been released as part of GitLab 11.x or earlier. Now that we're on GitLab 13, it's safe to remove migrations introduced in 11.x.
Previously, we've used squashed
gem to squash the migrations. This hasn't worked for me (and perhaps the gem isn't well enough maintained any more). Instead, I went with the following procedure:
- Create empty database
- Change application setting to dump
schema.rb
instead ofstructure.sql
(uncommentconfig.active_record.schema_format
) - Migrate database up to
20181228175414
- Delete all migrations <2019
- Replace
20181228175414
migration with what had been dumped intoschema.rb
- Make sure new initial migration indicates version 6.0 (otherwise defaults are being treated differently, for example)
- Delete old migration specs
Validation
In order to validate this gives the result, I performed the following steps:
- Uncomment
config.active_record.schema_format = :sql
(so we'll get aschema.rb
)
For both this branch and master
:
- Create empty database
rake db:migrate VERSION=20181228175414
- copy
db/schema.rb
Comparing both schema.rb
files yields no differences.
Doing the same with a SQL dump (structure.sql
) yields one notable difference:
On master
, we end up with this constraint:
ALTER TABLE ONLY public.pool_repositories
ADD CONSTRAINT fk_rails_95a99c2d56 FOREIGN KEY (shard_id) REFERENCES public.shards(id) ON DELETE RESTRICT;
On this branch, we have:
ALTER TABLE ONLY public.pool_repositories
ADD CONSTRAINT fk_rails_af3f8c5d62 FOREIGN KEY (shard_id) REFERENCES public.shards(id) ON DELETE RESTRICT;
Note the different constraint name. Fortunately, fk_rails_af3f8c5d62
is what we're also tracking in the latest schema: https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/structure.sql#L12305 . I don't see anything referencing the fk_rails_95a99c2d56
constraint, so we should be fine.