Initial configuration for Flyway

[antsab20]

Summary of change

Currently users have to manually run SQL scripts for migration.
A solution would be to use Flyway for automatic database migration at Runtime. This will make it easier to migrate and track migration changes.

Technical solution

Flyway migrations will be included in the postgresql-plugin:

Directory structure:

|- /db/
|- /migration/
|- /access_token_signing_key_dynamic_false
|- /access_token_signing_key_dynamic_true
|- /common

The reason why we have 3 directory for migration is because some migrations are conditionally applied or skipped. Therefore, when I am building the location where Flyway searches for migration scripts, I can add or remove them from location. Flyway also offers other solutions to solve such situations. One of them would be custom placeholders, but more documentation will be required to understand if placeholders are a feasible solution for this case.

The default naming convention for migration scripts is as follows: V{version}__{description}.sql . The {version} is used to order the scripts, while the description is there to give some context on the migration. Java migrations are also accepted.

Packaging:
The new directory structure will also have to be present inside the postgresql-plugin.jar. By default it was not. So I had to update the build.gradle jar task.

Implementation details:

When will it be run?

• Flyway migration will be run at Runtime, only once, after the user starts core application.

How to run migration for users that have manually run migration?

• Users who were utilizing the Core before the introduction of the Flyway migration feature have already been manually running migration. But Flyway does not have details about this, therefore we will need to set a starting point for database migration. For this we will use Flyway baseline feature. To calculate what will be the baseline we have who was the last migration run. Some migrations contain multiple SQL queries, but we can assume if one of them was successfully run, the entire migration was successful.

Will this feature work by default?

• This feature could be disabled by default for the sake of consistency for existing users. But they will be notified about this new feature, so if they decide to do this, they will only have to change the configuration to enable it.

What is the expected downtime during migration?

• When a new core version is released, the user will have to stop the Core that was running with an older version and start the Core with a newer version

Will there be any code changes required in Core?

• Yes, because there are migrations that will be skipped if a configuration if Core is present. Core will have to pass that value to plugin.

Related issues

Test Plan

In order to test this, you will have to run ./gradlew flywayMigrate

Documentation changes

Checklist for important updates

• A Flyway configuration in build.gradle + some dummy migration scripts

Remaining TODOs for this PR

• Add a flag which will prevent migration from running if the db is already up to date, or will have to run partial migration in case the db is partially updated.