+1 On 10/18/18, 7:49 PM, "Rawlin Peters" <rawlin.pet...@gmail.com> wrote:
>I'd like to propose we drop support for `goose down` in terms of doing >a Traffic Ops downgrade. > >Right now whenever you upgrade Traffic Ops you also need to run >`db/admin.pl upgrade` to migrate the DB to the latest version. This >step runs all unapplied migrations since the last DB migration was >applied. However, if something goes wrong with the deploy and TO needs >to be rolled back, you have to run `db/admin.pl down` X times if your >TO upgrade ran X migrations in order to get back to the pre-upgrade >state of the DB. There are also certain steps in `db/admin.pl upgrade` >that cannot be reversed with a `goose down`, because they are done in >patches.sql or seeds.sql. So even if you `db/admin.pl down` the >correct number of times to get back to the _original_ schema version, >it's likely that your data has actually changed irreversibly (but >maybe not in a very bad way). > >A much safer alternative to `db/admin.pl down` is to simply restore a >pre-upgrade copy of the DB. I think we should make that the >"supported" DB rollback process rather than the `goose down`. For dev >purposes I think it's fine to still include `goose down` steps in your >migrations, but I think we should build pre-upgrade DB copying into >the official upgrade process as well as restoration of the pre-upgrade >DB on rollback. > >Manually saving off a copy of the pre-upgrade DB should already be a >step in everyone's TO upgrade process, but I'm proposing we actually >build this functionality into the upgrade process itself, drop support >for `goose down`, and add support for DB restoration upon rollback. > >Initially I'd like to just get +1/-1 on this proposal, then we can >follow up and figure out the best way to implement it. > >- Rawlin
