Managing migration scripts or MyBatis Scheme Migration Extended

I think all developers somehow know the concept of “migration script”. As a rule, there is a sql-script, created to maintain the relevance of the database. The way to create and use migration scripts is quite easy, therefore, this process can also be done manually. I want to talk about a tool that in some places simplifies working with migration scripts.

MyBatis Schema Migrations

The interesting MyBatis data storage library (formerly known as iBatis) includes a migration scripts management tool. It works from the command line and is implemented for both Linux and Windows systems. The console script (bat, sh) with which we will work only transfers our commands to the corresponding java-class and executes it on the java-machine.
What can the library:

1. Displays a list of migration scripts
2. Determining the status of a specific migration script (already rolled up or not yet)
3. Displays the date the migration script was run
4. Creating a migration script template
5. Execution of migration scripts
6. Rollback changes
7. Randomly moving between database versions
8. Export migration scripts to a separate file. At the same time, you can specify which version of the migration scripts to which version should be exported.

When you first start MyBatis Schema Migrations, you can carefully create a migration script project structure that it understands.
The process of working with the utility looks like this (all commands are executed in the context of running the tool itself in the format migrates << command >>):

1. Initializing the migration script repository with the init command
2. Create a migration script, specifying the name of the script with the command new
3. In the created script preparation there are two blocks. We fill them in:
   • Migration script itself
   • The rollback script changes the current migration
4. We run migration scripts with the command up
5. We look at the status of scripts command status
6. If there are scripts (for example, appeared after updating the project through the version control system), run them with the command up
7. If you need to return to a specific state of the base, then we roll back the changes with the command down or version
8. We export a bunch of our migration scripts to a separate file, for example, to give the customer with the scripts command fromVersion toVersion, where fromVersion and toVersion define the range of exported data
9. In the case of outstanding scripts in the middle of the list, you can only run them using the pending command. The command is dangerous because other scripts may depend on the modified script.

Just like that you can monitor the status of the project database.
But not without its subtleties. So, in my linux utility, this utility refused to find the default migration script template. I had to set the path to my template file in the configuration file (migration.properties):
new_command.template=20110925094101_first_migration.sql
The utility commands should be executed while in the migration script project that we created using the init command. It is also possible to be located anywhere, but assign the --path parameter to each command.
You can learn more about working with MyBatis Schema Migrations from the official tutorial and from the official video, where an example of working with the tool is shown.

MyBatis Schema Migrations Extended (Migro)

Although the utility seemed interesting to me and it solves some problems, in the current implementation I also see some drawbacks that will appear with the implementation of this tool. The project is written in java and is distributed under the Apache License 2 license, which prompted me to create my own fork of this project, where I could implement the necessary features. I will say right away that I consider the myBatis migration tool project to be completely complete and I understand the vision of its developers about managing migration scripts. But I have my own vision of this and I believe that this tool is not quite suitable for use on large projects.

About what you need for a large project

What is already implemented in my project:

• Scripts can be grouped by build versions, which saves us from having to keep a long string of migration scripts for the entire project in one folder.
• You can edit an already created and fired migration script by calling the edit command for it.
• Modified files appear in the list as updated. You can update them using the pending command. Despite the redesign, the pending team is still unsafe.

What will be implemented:

• Manage grouping by build versions from the command line
• Execution of a specific migration script or arbitrary range
• Script export, specific build version
• Exporting scripts to a template file
• IDE integration
• Optimization and refactoring :)

Download here: https://github.com/evgenij-kozhevnikov/Migro
Source Project: myBatis
Video: Example of using myBatis Scheme Migration