sounds good to me On Tue, Jul 27, 2021 at 7:50 AM Zach Hoffman <zrhoff...@apache.org> 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 >
