[4.X] Make each module own their DB migration scripts

[freya022]

Changes

• Migration scripts were moved to their respective module
• The database module can now be freely used
  • It may be used with any RDBMS, but support of some features (particularly the supported types of parameter bindings) may vary between drivers
• Some migration scripts are vendor-specific
• The application commands cache only supports PostgreSQL

Upgrading from 3.X

Here I will explain the details of how it is done, then you will get the corresponding code to migrate in one go.

Moving the data to the new schema(s)

Considering you have used the migration code from "Using a database - Migrating the framework schema", this is how you can migrate your existing data to the new structure:

1. Replace the locations arguments with bc_database_scripts/generic and bc_database_scripts/<vendor> where <vendor> is either postgresql or H2
2. Run the migration
   • On PostgreSQL, the tables are moved using ALTER TABLE SET SCHEMA
   • On H2, new tables are created, and the data copied over
3. You should now see two new schemas: bc_components and bc_commands_app
4. Remove the BC migration code

Adding migration code for the new modules

For instructions on migrating the schema of relevant modules, see:

• BComponentsConfig for components
• BApplicationConfigBuilder#databaseCache if you use the database-backed application commands cache (it doesn't by default)

For the first run, you will need to replace the migrate() call with baseline(), after it is done, revert to migrate(), done!

Doing it in one go

Important

This assumes you have updated to 4.X and added both the BotCommands-components and BotCommands-commands-app modules

Suppose your existing code is:

Flyway.configure(getClass().getClassLoader())
            .dataSource(source)
            .schemas("bc")
            .locations("bc_database_scripts")
            .load()
            .migrate();

To do the whole migration, replace it with:

// Move tables from original schema
// You can safely remove this after running it once
Flyway.configure(getClass().getClassLoader())
            .dataSource(source)
            .schemas("bc")
            .locations("bc_database_scripts/generic", "bc_database_scripts/<vendor>")
            .failOnMissingLocations(true) // In case the locations above are wrong
            .load()
            .migrate();

// Recreates the Flyway schema history from the current state on the first run
// On further runs, attempts to migrate, as usual
Flyway.configure(getClass().getClassLoader())
            .dataSource(source)
            .schemas("bc_components")
            .locations("db/bc-migration/components/generic", "db/bc-migration/components/<vendor>")
            // TODO Remove this line after the first run
            .baselineOnMigrate(true) // Baselines on the first migration (i.e. marks the current schema as up to date)
            .load()
            .migrate();

// TODO remove this if you are using H2
Flyway.configure(getClass().getClassLoader())
            .dataSource(source)
            .schemas("bc_commands_app")
            .locations("db/bc-migration/app-commands/postgresql")
            // TODO Remove this line after the first run
            .baselineOnMigrate(true) // Baselines on the first migration (i.e. marks the current schema as up to date)
            .failOnMissingLocations(true) // In case the locations above are wrong
            .load()
            .migrate();