Add new subcommand to update migrations that contain breaking changes

[kvch]

This PR adds a new subcommand called update. It updates migrations that contain breaking changes in the selected folder.

Usage:
  pgroll update <directory> [flags]

Examples:
update ./migrations

Flags:
  -h, --help    help for update
  -j, --json    Output migration file in JSON format instead of YAML

Dev notes

The new migrations.FileUpdater follows the chain of responsibility design pattern. In the FileUpdater you can register new updater functions (migrations.updaterFn) for any pgroll migration. The file updater iterates over all operations in a migration and run the registered updater functions in order.

The ordering of the updater functions is important. Please always add a new updater function to the end of the list.

Closes #770

[andrew-farries]

Looks good; left some comments 👍

[andrew-farries]

I don't think we need this flag. IMO the update command should awlays operate on all migrations in the given directory.

I'm not sure what the use-case is for only updating the local migations that have yet to be applied.

In any case, source control allows users to only commit the updates they want.

I'd remove the flag and make the command always operate on all migrations.

[kvch]

The --local flag is running on all local files, not just unapplied ones. By default pgroll updates only unapplied migrations. I think the flag is valuable when you pull all migrations from the database and run the command with --local. Or when you do not specify the flag you just update the local, unapplied files because we do not want to rewrite the history in the database. WDYT?

[andrew-farries]

I'm still in favour of removing the flag and having the command always run on all files in the local directory.

The use case for this command AIUI is:

1. A user upgrades pgroll from version x to version y.
2. Version y makes a breaking change to the YAML/JSON format for a particular operation.
3. The user has already applied some migrations in the old format to their target database.

Now as a user I want to get all migrations into the new format so that I have a set of migration files for my project that I can use with the version y of pgroll.

1. The user runs pgroll update migrations/ to rewrite the migration files.
2. The user commits those changes to source control.

Now I can bootstrap other DBs from scratch with the migration files in migrations/.

I don't see the use case for only updating the migration files that have yet to be applied to the database?

we do not want to rewrite the history in the database

This command only ever touches local files, not migrations in the database though right?

[kvch]

This command only ever touches local files, not migrations in the database though right?

Yes.

[andrew-farries]

Looks good; left a few comments.

[andrew-farries]

I'm still in favour of removing the flag and having the command always run on all files in the local directory.

The use case for this command AIUI is:

1. A user upgrades pgroll from version x to version y.
2. Version y makes a breaking change to the YAML/JSON format for a particular operation.
3. The user has already applied some migrations in the old format to their target database.

Now as a user I want to get all migrations into the new format so that I have a set of migration files for my project that I can use with the version y of pgroll.

1. The user runs pgroll update migrations/ to rewrite the migration files.
2. The user commits those changes to source control.

Now I can bootstrap other DBs from scratch with the migration files in migrations/.

I don't see the use case for only updating the migration files that have yet to be applied to the database?

we do not want to rewrite the history in the database

This command only ever touches local files, not migrations in the database though right?

[kvch]

Updated the PR. I will update the guide in my other PR after this gets merged.