Concepts-->Migrations
https://flywaydb.org/documentation/migrations
Overview
With Flyway all changes to the database are called migrations.
Migrations can be either versioned or repeatable.
Versioned migrations come in 2 forms: regular and undo.
Versioned migrations have a version, a description and a checksum. The version must be unique.
The description is purely informative for you to be able to remember what each migration does.
The checksum is there to detect accidental changes. Versioned migrations are the most common type of migration. They are applied in order exactly once.
Optionally their effect can be undone by supplying an undo migration with the same version.
Repeatable migrations have a description and a checksum, but no version. Instead of being run just once, they are (re-)applied every time their checksum changes.
Within a single migration run, repeatable migrations are always applied last, after all pending versioned migrations have been executed. Repeatable migrations are applied in the order of their description.
By default both versioned and repeatable migrations can be written either in SQL or in Java and can consist of multiple statements.
Flyway automatically discovers migrations on the filesystem and on the Java classpath.
To keep track of which migrations have already been applied when and by whom, Flyway adds a schema history table to your schema.
Versioned Migrations
The most common type of migration is a versioned migration. Each versioned migration has a version, a description and a checksum. The version must be unique. The description is purely informative for you to be able to remember what each migration does. The checksum is there to detect accidental changes. Versioned migrations are applied in order exactly once.
Versioned migrations are typically used for:
- Creating/altering/dropping tables/indexes/foreign keys/enums/UDTs/…
- Reference data updates
- User data corrections
Here is a small example:
CREATE TABLE car (
id INT NOT NULL PRIMARY KEY,
license_plate VARCHAR NOT NULL,
color VARCHAR NOT NULL
);
ALTER TABLE owner ADD driver_license_id VARCHAR;
INSERT INTO brand (name) VALUES ('DeLorean');
Each versioned migration must be assigned a unique version. Any version is valid as long as it conforms to the usual dotted notation.
For most cases a simple increasing integer should be all you need.
However Flyway is quite flexible and all these versions are valid versioned migration versions:
- 1
- 001
- 5.2
- 1.2.3.4.5.6.7.8.9
- 205.68
- 20130115113556
- 2013.1.15.11.35.56
- 2013.01.15.11.35.56
Versioned migrations are applied in the order of their versions. Versions are sorted numerically as you would normally expect.
Repeatable Migrations
Repeatable migrations have a description and a checksum, but no version. Instead of being run just once, they are (re-)applied every time their checksum changes.
This is very useful for managing database objects whose definition can then simply be maintained in a single file in version control. They are typically used for
- (Re-)creating views/procedures/functions/packages/…
- Bulk reference data reinserts再次插入
Within a single migration run, repeatable migrations are always applied last, after all pending versioned migrations have been executed. Repeatable migrations are applied in the order of their description.
It is your responsibility to ensure the same repeatable migration can be applied multiple times. This usually involves making use of CREATE OR REPLACE
clauses in your DDL statements.
Here is an example of what a repeatable migration looks like:
CREATE OR REPLACE VIEW blue_cars AS
SELECT id, license_plate FROM cars WHERE color='blue';
SQL-based migrations
Migrations are most commonly written in SQL. This makes it easy to get started and leverage any existing scripts, tools and skills.
It gives you access to the full set of capabilities of your database and eliminates the need to understand any intermediate translation layer.
SQL-based migrations are typically used for
- DDL changes (CREATE/ALTER/DROP statements for TABLES,VIEWS,TRIGGERS,SEQUENCES,…)
- Simple reference data changes (CRUD in reference data tables)
- Simple bulk data changes (CRUD in regular data tables)
Naming
In order to be picked up by Flyway, SQL migrations must comply遵从 with the following naming pattern:
The file name consists of the following parts:
- Prefix:
V
for versioned (configurable),U
for undo (configurable) andR
for repeatable migrations (configurable) - Version: Version with dots or underscores separate as many parts as you like (Not for repeatable migrations)
- Separator:
__
(two underscores) (configurable) - Description: Underscores or spaces separate the words
- Suffix:
.sql
(configurable)
Discovery
Flyway discovers SQL-based migrations both on the filesystem and on the Java classpath. Migrations reside in one or more directories referenced by the locations
property.
Locations with the filesystem:
prefix target the file system.
Unprefixed locations or locations with the classpath:
prefix target the Java classpath.
New SQL-based migrations are discovered automatically through filesystem and Java classpath scanning at runtime.
Once you have configured the locations
you want to use, Flyway will automatically pick up any new SQL migrations as long as they conform to the configured naming convention.
This scanning is recursive. All migrations in non-hidden directories below the specified ones are also picked up.
Syntax
Flyway supports all regular SQL syntax elements including:
- Single- or multi-line statements
- Single- (–) or Multi-line (/* */) comments spanning complete lines
- Database-specific SQL syntax extensions (PL/SQL, T-SQL, …) typically used to define stored procedures, packages, …
Additionally in the case of Oracle, Flyway also supports SQL*Plus commands.
Placeholder Replacement
In addition to regular SQL syntax, Flyway also supports placeholder replacement with configurable pre- and suffixes. By default it looks for Ant-style placeholders like ${myplaceholder}
.
This can be very useful to abstract differences between environments.
Transactions
By default, Flyway always wraps the execution of an entire migration within a single transaction.
Alternatively you can also configure Flyway to wrap the entire execution of all migrations of a single migration run within a single transaction by setting the group
property to true
.
If Flyway detects that a specific statement cannot be run within a transaction due to technical limitations of your database, it won’t run that migration within a transaction. Instead it will be marked as non-transactional.
By default transactional and non-transactional statements cannot be mixed within a migration run. You can however allow this by setting the mixed
property to true
.
Important Note
If your database cleanly supports DDL statements within a transaction, failed migrations will always be rolled back (unless they were marked as non-transactional).
If on the other hand your database does NOT cleanly supports DDL statements within a transaction (by for example issuing an implicit commit before and after every DDL statement), Flyway won’t be able to perform a clean rollback in case of failure and will instead mark the migration as failed, indicating that some manual cleanup may be required.
Query Results
Migrations are primarily meant to be executed as part of release and deployment automation processes and there is rarely the need to visually inspect the result of SQL queries.
There are however some scenarios where such manual inspection makes sense, and therefore Flyway Pro and Enterprise Edition also display query results in the usual tabular form when a SELECT
statement (or any other statement that returns results) is executed.
Schema History Table
To keep track of which migrations have already been applied when and by whom, Flyway adds a special schema history table to your schema.
You can think of this table as a complete audit trail of all changes performed against the schema.
It also tracks migration checksums and whether or not the migrations were successful.
Read more about this in our getting started guide on how Flyway works.
Migration States
Migrations are either resolved or applied. Resolved migrations have been detected by Flyway’s filesystem and classpath scanner. Initially they are pending. Once they are executed against the database, they become applied.
When the migration succeeds it is marked as success in Flyway’s schema history table.
When the migration fails and the database supports DDL transactions, the migration is rolled back and nothing is recorded in the schema history table.
When the migration fails and the database doesn’t supports DDL transactions, the migration is marked as failed in the schema history table, indicating manual database cleanup may be required.
Versioned migrations whose effects have been undone by an undo migration are marked as undone.
Repeatable migrations whose checksum has changed since they are last applied are marked as outdated until they are executed again.
When Flyway discovers an applied versioned migration with a version that is higher than the highest known version (this happens typically when a newer version of the software has migrated that schema), that migration is marked as future.
Concepts-->Migrations的更多相关文章
- go Rails 知识点,Concepts Series:url和parameter; 建立Rails App Templates;报错页面debug; counter_cache
Rails Concepts Series: https://gorails.com/series/rails-concepts 基本都是免费的 一些细小的知识点,很有帮助. URL和paramete ...
- Code First Migrations
在MVC开发当中难免会对类进行修改,修改后再次运行就会出现异常,提示上下文的模型已在数据库创建后发生改变. 支持“AppContext”上下文的模型已在数据库创建后发生更改.请考虑使用 Code Fi ...
- EF Code First Migrations数据库迁移
1.EF Code First创建数据库 新建控制台应用程序Portal,通过程序包管理器控制台添加EntityFramework. 在程序包管理器控制台中执行以下语句,安装EntityFramewo ...
- EntityFramework 7 Migrations 迁移命令
示例代码: using Microsoft.Data.Entity; using System.Collections.Generic; namespace ClassLibrary1 { publi ...
- 新书到手 TRANSACTION PROCESSING:CONCEPTS AND TECHNIQUES
新书到手 TRANSACTION PROCESSING:CONCEPTS AND TECHNIQUES Jim Gray大神的著作 本文版权归作者所有,未经作者同意不得转载.
- entity Framework codefirst Migrations
一次数据迁移的记录 首先在vs工具里面使用打开程序包管理器控制台 在控制台上面选择程序集为数据访问层 注意配置生成app里面的连接字符串 在控制台输入 Enable-Migrations 会自动生成一 ...
- RS-232, RS-422, RS-485 Serial Communication General Concepts(转载)
前面转载的几篇文章重点介绍了UART及RS-232.在工控领域除了RS-232以外,常用的串行通信还有RS-485.本文转载的文章重点介绍了RS-232.RS-422和RS-485. Overview ...
- Code First Migrations 数据迁移小记
用了codefirst后一个很大的问题就是代码中的属性字段与数据库中表的同步问题,删掉数据库重新生成当然可以解决,不过数据就丢失了(当然通过代码中初始化数据库添加数据也可以解决,初始化的任务可以通过重 ...
- Only the sqlmigrate and sqlflush commands can be used when an app has migrations.
samcao@samcao-Lenovo-IdeaPad-Y470:~/caodjango/caossh$ python manage.py sqlall getssh System check id ...
- EF架构~CodeFirst生产环境的Migrations
回到目录 Migrations即迁移,它是EF的code first模式出现的产物,它意思是说,将代码的变化反映到数据库上,这种反映有两种环境,一是本地开发环境,别一种是服务器的生产环境,本地开发环境 ...
随机推荐
- windows环境下搭建RocketMQ
https://blog.csdn.net/hsl_1990_08_15/article/details/80077552 安装完rocketmq后,报磁盘空间不足,只需要修改启动脚本runbroke ...
- 33网络通信之Epoll模型
多路复用并发模型 -- epoll 监控事件 events EPOLLIN fd可读 EPOLLOUT fd可写 EPOLLPRI ...
- Swift 了解(2)
循环(Loops) 1. For条件递增语句 ; counter < ; counter++ ) { liftWeights( ) } 语法是这样的:用for作为循环的开始,告诉Xcode你要声 ...
- C# 设置按钮快捷键
参考自:http://www.csharpwin.com/csharpspace/3932r8132.shtml 一.C# button快捷键之第一种:Alt + *(按钮快捷键) 在Button按钮 ...
- Spring boot学习1 构建微服务:Spring boot 入门篇
Spring boot学习1 构建微服务:Spring boot 入门篇 Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Spring应用的初始搭建以及开发过程.该框 ...
- 15类Android通用流行框架
15类Android通用流行框架 Android流行框架 缓存 DiskLruCache Java实现基于LRU的磁盘缓存 图片加载 Android Universal Image Loader 一个 ...
- linux下postgresql的连接数配置
1.查询当前连接数: select count(*) from pg_stat_activity; 2.查询最大连接数 show max_connections; 3.修改最大连接数 SHOW con ...
- bootstrapValidator验证表单后清除当次验证的方法
用bootstrapValidator的resetForm()方法: <!-- // create server begin --> <div class="modal f ...
- Installing Android Studio
To set up Android Studio on Windows: Launch the .exe file you just downloaded. Follow the setup wiza ...
- C# Http文件上传下载
C# Http文件下载公共类(支持断点续传) http://www.cnblogs.com/hayden/archive/2012/04/26/2472815.html C# Http方式下载文件到本 ...