Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "how to use the database migration artifact Flyway". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Data migration

The professional term for the scenario we mentioned earlier is data migration, so why is there a data migration scenario? I took a picture from the official website and you can take a look at it. Although it may not be the same as my actual development, it is almost similar to this scenario, and there are multiple environments. We can see that although our code can be controlled through version iteration, our database is not, and very often we forget whether the script has been executed, which is very difficult to rely on human memory.

Flyway

Flyway is a tool used to solve database migration like this. After connecting to Flyway, a default data table named flyway_schema_history is generated in the database to track changes in the database. When the program starts, Flyway will look for the migration script under the file system or classpath path. Each migration step has a corresponding naming rule. Flyway migrates according to the version number of the file. After each migration, a record similar to the following is inserted in the flyway_schema_history table to record the script file and check code and other information corresponding to the version:

Only the highest version of the script is executed each time it starts, and if the version remains the same, the script cannot be started if it changes.

Migration type of Flyway

Version migration

The most common migration is versioned migration, each migration will be the corresponding migration version, the migrated version must be globally unique, the biggest feature of version migration is that it is only executed in turn.

Undo migration

Each undo migration corresponds to a version migration, that is to say, the cancellation migration exists for the version migration, each cancellation migration corresponds to the version migration one by one, and the corresponding version number must be the same.

Repeatable migration

Repeatable migration has a description and checkcode, but no version number, and the program will be executed each time it starts if it finds a change in the script file.

SQL-based migration

The above-mentioned types are all based on SQL files, but the naming format of each type is different. The following figure is truncated from the official website. You can see that each type of file should be ordered in the following format, where the Separator is two underscores.

It is mainly divided into the following parts:

Prefix: prefix, different types use different prefixes, version migration uses V, undo migration uses U, repeatable migration uses R, of course, these are configurable.

Version: version number, you can use dot symbols or single underscore links

Separator: separator, two underscores, can also be configured

Description: version descriptions can be separated by underscores and spaces

Suffix: suffix, usually .sql

SpringBoot project connects to Flyway

It is very easy to connect the SpringBoot project to Flyway, which can be divided into the following steps. Let's take a look at it in turn.

Add dependency

Org.flywaydb flyway-core

Just add the above dependency to the project pom.xml file.

Increase configuration

# enable flyway spring.flyway.enabled=true # disable cleaning data table spring.flyway.clean-disabled=true # whether there is a database spring.flyway.baseline-on-migrate=true # base version number, increment spring.flyway.baseline-version=0 # the location where the migration script is stored spring.flyway.locations=classpath:db/migration

Here, because in many cases we do not start using Flyway for a new project, but are introduced during the iteration of the project, the above configuration spring.flyway.clean-disabled=true must be disabled. The above configurations are very simple to configure because they have been inherited into SpringBoot.

Migration script

The naming rules of file scripts are as mentioned above, and we use version migration here. We create a version of the SQL file and put it in the corresponding classpath folder, the file is called V1.2__create_test_table.sql, the contents of the file are as follows, and then we start the project.

CREATE TABLE `test_ Table` (`id` int (11) NULL COMMENT 'ID', `name` varchar (255) NULL COMMENT' Name')

During startup, we see the following log, which shows the current version, as well as the migrated version.

Let's look at the database. First of all, test_table has been created successfully.

In addition, when we look at the flyway_schema_history table, we will find that there is already one more version of data, so we have successfully intervened in Flyway.

This is the end of the introduction to "how to use the database migration artifact Flyway". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.