Flyway help automate database management script Raiders

Original Address: Liang Gui Zhao's blog

Blog address: http://blog.720ui.com

Welcome to public concern number: "server-side thinking." A group of the same frequency who grow up together, along with sophisticated, breaking the limitations of cognition.

Today to discuss an interesting topic: We can be achieved by the project Git version control; continuous integration by Jenkins, then for database level, we still rely on handmade run SQL scripts, to which we in multi-environment (development environment, test environment, pre-development environment, production environment) how to ensure the correctness of its latest and SQL scripts?

As we all know, manual operation is very easy to go wrong, we should allow the program to help automate the management and migration. Today, I recommend an open source database migration tool Flyway.

Flyway not only support MySQL, it can also support very many other databases.

In fact, Spring Boot has the perfect integration of the Flyway. In this regard, we can very easily use it. First, we introduce Maven dependencies. (Note that we also need to project in spring-boot-starter-jdbc, mysql-connector-java-dependent)

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>

In addition, we configure the relevant options in application.yml in. Spring Boot default classpath: // db / scanning Migration under the migration directory. Here, the author spring.flyway.locations be adjusted to db / sql.

spring:
  flyway:
    enabled: true
    baseline-on-migrate: true
    locations: [classpath:db/sql]

When the system starts, it will automatically create flyway_schema_history file. (Of course, you can manually create your own). This table is Flyway metadata tables, which keeps a record of each migration, the checksum value recorded version and SQL scripts contain migration script. When a new SQL scripts are scanned, Flyway resolve the version number of the SQL script, and and metadata tables contrast, if the SQL script version of the update, it will execute the SQL file on the specified DB, otherwise skip the SQL file.

CREATE TABLE `flyway_schema_history` (
  `installed_rank` int(11) NOT NULL,
  `version` varchar(50) DEFAULT NULL,
  `description` varchar(200) NOT NULL,
  `type` varchar(20) NOT NULL,
  `script` varchar(1000) NOT NULL,
  `checksum` int(11) DEFAULT NULL,
  `installed_by` varchar(100) NOT NULL,
  `installed_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `execution_time` int(11) NOT NULL,
  `success` tinyint(1) NOT NULL,
  PRIMARY KEY (`installed_rank`),
  KEY `flyway_schema_history_s_idx` (`success`)
)

Then, we create a SQL script manually initiated in the db / sql: V1.1__INIT_DB.sql.

DROP TABLE IF EXISTS `tag`;

CREATE TABLE `tag` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `gmtCreate` date DEFAULT NULL,
  `gmtModified` date DEFAULT NULL,
  `title` varchar(32) DEFAULT NULL,
  `parentId` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Then, after the program starts again, it will automate posted to the database.   

Here, the need to supplement the knowledge: the version comparison rule Flyway. Left to take its principles, the absence of a 0 instead. Higher than 1.1, for example 1.0, higher than the 1.1 version 1.1.1, 1.1.1 and 1.1.01 and consistent. In addition, they will perform in accordance with the order and the release order.

In addition, Flyway not only supports DDL, also supports DML (insert, update, delete) and so on. Therefore, we can then create a V1.2__INSERT_TAG_DATA.sql file to verify.

INSERT tag(title, parentId) values('java', 0);
INSERT tag(title, parentId) values('spring', 0);

Finally, we have to discuss in the next Flyway to support the common types of migration:

• Versioned migrations: the database upgrade scripts
• Repeatable migrations: re-execute when the script checksums change will be re-executed.

• prefix: 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 separators between the digital or underscore _.
• separator: a separate version identification and description information, the default is two underscores __
• description: underline or may be separated by a space between the description information, text
• suffix: subsequent identification, default .sql

To summarize, Flyway to help us automate the migration version maintenance and management of databases through metadata (flyway_schema_history).

Written at the end

[Server] thinking: We talk with the core server technology to explore the architecture and project experience in front-line combat Internet. Let alone all of R & D personnel to find their own circle of exchange, to explore. Here, we can upgrade the cognitive connection top technical Daniel, connection excellent way of thinking, connected to the shortest path to solve the problem, all fine way to connect, to break the limitations of cognition.

More exciting articles, all in "server-side thinking"!

This article from the blog article multiple platforms OpenWrite release!