Flyway and Liquibase are commonly used in Java project DB migration tool, from ease of use to see, Flyway easier than Liquibase, from the number of star github to see, flyway more popular.
==============================
Flyway command-line tools and maven plugin
============= =================
for SpringBoot project development, in fact, does not require special installation flyway command-line tools and maven plugin, SpringBoot start operation will be executed DB migrate automatically. for other flyway operation , you need to use the command line tools or maven plugin.
flyway provides a command-line tool, commonly used commands include:
Clean: remove all the database objects created, including users, tables, views, and so be careful not to perform clean operation on the production library..
Migrate: the database and then click Apply version changes.
Info: get At present the state of the database that the migration has been completed, those pending execution time of the migration of all migration and the results..
the validate: verify that the Apply script if there is a change, Flyway migration default do first of the validate.
Baseline: existing database structure based on migration benchmark generates a script.
repair: repair command try not to use, repair scenarios are: 1. remove the failed migration records 2. already applied SQL script is modified, we want to re-apply the SQL script.
maven plugin, maven plugin to see the latest https://mvnrepository.com/artifact/org.flywaydb/flyway-maven-plugin
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>4.0.3</version>
</plugin>
maven plugin command, mvn flyway: migrate
==============================
Flyway works
================ ==============
Flyway need to create a metdata in the DB table (the default table named flyway_schema_history), keeps a record of every time migration in the table, the record contains the migration scripts checksum value of the version number, and SQL scripts. when a new SQL scripts are scanned, Flyway resolve the version number of the SQL script, and and migration contrast metadata table already apply the if the SQL script version of the update, it will in execute the SQL file on the specified DB, otherwise skip the SQL file.
Comparison of two flyway version number, left-justified principle, replaced by 0 Absence example as follows:.
. 1.2.9.4 1.2.9 version than the
high version 1.2.9.4 than 1.2.10
1.2.10 and version 1.2.010 as high numbers, leading 0 for each part of the version number will be ignored.
Flyway SQL files can be divided into two categories: Versioned and Repeatable.
Versioned migration for the upgrade version, each version has a unique version number and can only apply once.
Repeatable migration refers to migration can be repeated loading, once the SQL script of the checksum change, flyway will reapply the script. it is not for the updated version, always kind of migration was only executed after the versioned migration execution.
By default, Migration SQL naming rules as shown below:
Wherein the file name consists of, in addition to the default configuration, but some parts may be custom rule.
prefix: configurable prefix identifier, the default value of V represents Versioned, R represents Repeatable
Version: the version identification number, composed of one or more digital, the available point between separators numbers or underscores _.
Separator: can be configured for version identification and description of the partition, the default is two underscores __
description: description, or may be separated by an underscore character space between
suffix: configurable subsequent identification, default .sql
flyway the metadata table as follows:
CREATE TABLE flyway_schema_history
(
installed_rank INT NOT NULL,
version VARCHAR(50),
description VARCHAR(200) NOT NULL,
type VARCHAR(20) NOT NULL,
script VARCHAR(1000) NOT NULL,
checksum INT,
installed_by VARCHAR(100) NOT NULL,
installed_on TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
execution_time INT NOT NULL,
success TINYINT(1) NOT NULL,
PRIMARY KEY (installed_rank),
INDEX flyway_schema_history_s_idx (success)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
==============================
pom.xml
================= =============
the Spring-the Boot-Starter-parent package does not use the latest 2.0.5, the latest version is always cause HikariPool could not be initialized, so the choice of version 2.0.4
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.4.RELEASE</version>
<relativePath /> <!-- lookup parent from repository -->
</parent>
flyway in fact depend only spring-boot-starter-jdbc package,
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
Plus spring-boot-maven-plugin, generates fat jar.
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
==============================
application.properties parameters
================ ==============
## db source attribute set spring.datasource.url = JDBC: MySQL: // localhost: 3306 / World spring.datasource.username = the root spring.datasource.password toor = ## is set flyway properties spring.flyway.cleanDisabled = to true # Flyway of clean command removes all table under the specified schema, overkill, it should be cut out. spring.flyway.enabled = to true # enable or disable Flyway spring.flyway.locations = the CLASSPATH: db / Migration # set SQL scripts given directory, the plurality of paths separated by commas, such as the value of CLASSPATH: DB / Migration, filesystem: / SQL-Migrations spring.flyway.baselineOnMigrate to true = # If a schema includes other tables, but not flyway schema history table, then before executing the flyway migrate command, you must first perform flyway baseline command. # set spring.flyway.baseline-on-migrate after true, flyway when needed baseline will automatically perform a baseline. spring.flyway.baselineVersion = 1 # baseline version number specified, a default value, lower than the version number of the SQL file, the migrate when they were ignored. # spring.flyway.encoding = # Encoding of SQL Migrations (default: . 8-UTF) spring.flyway.table = flyway_schema_history_myapp # flyway set of metadata table, default flyway_schema_history spring.flyway.outOfOrder to true = # open development environment best outOfOrder, production environment close outOfOrder. # spring.flyway.schemas = # of control required flyway schema List, then the default, when the schema dbsource.connection on the direct use, a plurality of schema can be specified, but only the established table in the first metadata schema, also only the first a schema application migration sql script, but flyway Clean command will in turn perform again in these schema.
More parameters see https://flywaydb.org/documentation/configfiles, it should be noted that, with these parameters to springboot2 project, you need to add spring. Prefix.
==============================
Flyway best practices
================ ==============
1. SQL name of the file
migration SQL development and production environments are not shared. development process is often more than collaborative development, DB migration is also relatively frequent, so SQL script many of them. and the production environment DB migration is often done by the DBA, each upgrade is usually required to submit a SQL script.
(1). SQL development environment file timestamps are recommended as the version number.
Development environment SQL file timestamps are recommended as the version number, will not lead to the development of people with the version number of contention, while together with the version number of the production environment, in this case, the future hand-merge into a production environment V1.2d migration script is also more convenient, SQL file example:
V20180317.10.59__V1.2_Unique_User_Names.sql
V20180317.14.59__V1.2_Add_SomeTables.sql
(2) The production environment SQL file should be manually merge the development environment of SQL scripts, the version number in accordance with normal versions, such V2.1.5_001__Unique_User_Names.sql
After 2. migration SQL scripts should no longer be modified.
3. spring.flyway.outOfOrder value of true / false
for the development environment, it may be more than collaborative development, it is likely to apply their latest native SQL code, and then found other colleagues Earlier SQL code submitted not apply, so development environment should set spring.flyway.outOfOrder = true, so flyway will be able to load missed the old version of SQL files; and the production environment should be set spring.flyway.outOfOrder = false
4. The system common to a plurality of DB schema
often multiple utility system a DB schema, which is different when using different spring.flyway.table system metadata table settings, default flyway_schema_history
Transfer: https://www.cnblogs.com/harrychinese/p/springboot_flyway.html