On Tue, Oct 23, 2018 at 11:10 AM David Neuman <david.neuma...@gmail.com> wrote: > > Individual developers and those that merge their PRs should be responsible > for developing and testing the `goose down` portion of a migration, this > does not change. > The whole argument is that relying on goose down for rollbacks is less than > ideal because you have to run it 1 time per migration that was applied > during an upgrade. This is why Rawlin is proposing a different solution of > creating a database snapshot and upgrade time that can be used in case of > rollback.
Yes, that is correct. Ideally we should plan to include basic up/down DB migration testing within the CI, so that we at least know that the migration SQL will run without error on a representative set of data (Kabletown). > On Tue, Oct 23, 2018 at 10:56 AM Gray, Jonathan <jonathan_g...@comcast.com> > wrote: > > > If we're removing goose down from the downgrade procedure, but still > > requiring support for it, doesn't that just make finding issues with it > > more difficult since fewer use cases would use that codepath? There will be two different supported procedures: 1. the `goose down` way 2. the `pgrestore` way Ideally we will have basic, automated test that test both of those procedures to exercise those codepaths.
