After abort, generate-schema-query returns the aborted search_path

[chiroptical]

$ pgcli db
> \dn
+--------------------------------+-------------+
| Name                           | Owner       |
|--------------------------------+-------------|
| migration_5_make_name_not_null | chiroptical |
| public                         | postgres    |
| reshape                        | chiroptical |
+--------------------------------+-------------+
$ reshape migrate
Applying 1 migrations

Migrating '6_make_name_null_again':
  + Altering column "name" on "users" done

...
$ reshape abort
Aborting '6_make_name_null_again' done
$ reshape generate-schema-query
SET search_path TO migration_6_make_name_null_again

However, if you look at \dn in pgcli the schema doesn't exist.

[fabianlindfors]

Hi, Barry!

This is actually deliberate although probably not very well explained. generate-schema-query doesn't fetch the current migration from the database but from the local migration files. This is important because the schema an application should use isn't always the latest one but the one it was designed for. If it fetched the latest one, then that could cause failures if for example a migration was in progress and the old application restarted for some reason.

It also has the added benefit of needing a running database when getting the schema query to use, which might be done in a build step or similar.

[chiroptical]

Right! I sort of find this interface odd fwiw.

You could initialize the program with RESHAPE_SCHEMA_QUERY=this_apps_current_schema and potentially avoid confusion when someone inevitably does what I just did? Then, reshape get-schemas could return the current active schemas. Also, what happens when someone starts to run an app and then aborts? But another version of the app is still using the schema you just deleted?

[fabianlindfors]

It's definitely odd but necessary to actually achieve zero-downtime migrations.

Aborts should only be performed after the new application has been rolled backed and the old application is still running. So the process looks like this:

1. Old application is running and we want to deploy a new version with schema changes
2. Run reshape migrate which starts the migration
3. Deploy the new application (and keep the old application running)
4. Notice that something is wrong and remove the new application instances
5. Run reshape abort once they have been rolled back and only the old application instances remain

Does that make more sense?