down with goose! On Tue, Jul 27, 2021 at 4:09 PM Dave Neuman <[email protected]> wrote:
> sounds good to me > > On Tue, Jul 27, 2021 at 7:50 AM Zach Hoffman <[email protected]> wrote: > > > Hi ATC, > > > > All good things eventually come to an end, but so does Goose. I have a PR > > out there that gets us using Migrate < > > https://github.com/golang-migrate/migrate> instead of Goose: > > https://github.com/apache/trafficcontrol/pull/6057 > > > > The big improvement is that Migrate is compiled into `db/admin` as a > > library. It does not need to be installed after installing Traffic Ops, > you > > already have it because the Traffic Ops RPM includes the `db/admin` tool. > > Benefits of this: > > • Traffic Ops no longer requires an Internet connection to run > > `postinstall` script. > > • Golang has been removed as a dependency from Traffic Ops. Although it > was > > not listed in the RPM spec, building Goose also required Git, which is > also > > no longer needed. > > • Goose required CGO, which precluded building a Traffic Ops RPM > targeting > > x86_64 Linux from other platforms like macOS and Windows if we ever ended > > up including the `goose` binary in the Traffic Ops RPM. This is no longer > > an issue. > > > > Compatibility features: > > • The database config file stays the same, you can keep using your > existing > > `dbconf.yml` as-is. > > • With the exception of `db/admin status`, all `db/admin` commands work > > like they used to (`db/admin status` explained below in the Differences > > section). For example, the command to run the migrations is still > `db/admin > > -env production migrate`. > > • Although the "up" and "down" migrations are split into separate files > > now, the contents of each existing migration are otherwise unmodified, > > other than removing Goose annotations like `+goose Up` and `+goose > > StatementBegin`. > > • No extra migration steps should be necessary, you can run `db/admin > -env > > production migrate` to migrate from Goose (which uses the > > `goose_db_version` table) to Migrate (which uses the `schema_migrations` > > table), meaning that Migrate will start at the migration version that > Goose > > used. The `goose_db_version` table is renamed to > `goose_db_version_unused` > > to preserve the Goose migration history while ensuring that only Migrate > is > > used going forward. If for any reason you do want to go back to Goose, > you > > can run the `00000000000000_init.down.sql` migration to rename the Goose > > table back to `goose_db_version`, so this is a non-destructive change. > > • The `install_goose.sh` script still exists in the repo, it just does > not > > do anything. It will be removed in a future ATC release. > > > > As a new feature, you can now create migrations directly from `db/admin` > > using `db_admin create_migration NAME`. Migrations created this way have > > 16-digit timestamps (as opposed to the 14-digit timestamps that `goose > > create` produced) and contain the Apache License 2.0. > > > > Differences: > > • Migrate keeps track of the migration version and "dirty" status (true > or > > false) in the `schema_migrations` table. If "dirty" is `true`, that means > > that the last migration to run failed. If it is set, the "dirty" flag > needs > > to be cleared manually. > > • Other than storing the version of the last migration to have run, > Migrate > > does *not* keep track of which migrations in the past have run. If a new > > migration is created with a timestamp before the current migration > version, > > Migrate will ignore that migration. > > • `db/admin status` is now an alias for `db/admin dbversion`. This is > > because `db/admin status` was a wrapper for `goose status`, which printed > > the status of each migration. `db/admin status` has been deprecated, > > pending removal in a future ATC release. > > • Because each "up" migration and its corresponding "down" migration are > > split into separate files, and because there are no longer any Goose > > annotations, Goose cannot use the new Migrate migrations. > > > > That's it! Thoughts and suggestions are welcome both in the PR and here > on > > the mailing list. > > > > -Zach > > >
