I think this sounds reasonable assuming we work out the details later. +1 On Fri, Oct 19, 2018 at 07:59 Dave Cardosi (dcardosi) <[email protected]> wrote:
> +1 > > On 10/18/18, 7:49 PM, "Rawlin Peters" <[email protected]> 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 > >
