gabadi / flyway-play

Play modules for Flyway

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

flyway-play

Build Status

Flyway module for Play 2.4 or later. It aims to be a substitute for play-evolutions.

This module is successor of tototoshi/play-flyway, which is a Play Plugin supporting Play 2.1 ~ 2.3.

Features

  • Based on Flyway
  • No 'Downs' part.
  • Independent of DBPlugin(play.api.db).

Install

build.sbt

libraryDependencies ++= Seq(
  "org.flywaydb" %% "flyway-play" % "2.0.1"
)

conf/application.conf

play.modules.enabled += "org.flywaydb.play.PlayModule"

Getting Started

Place migration scripts

A migration script is just a simple SQL file.

CREATE TABLE FOO (.............

Place your migration scripts in conf/db/migration/${dbName} .

playapp
├── app
│   ├── controllers
│   ├── models
│   └── views
├── conf
│   ├── application.conf
│   ├── db
│   │   └── migration
│   │       ├── default
│   │       │   ├── V1__Create_person_table.sql
│   │       │   └── V2__Add_people.sql
│   │       └── secondary
│   │           ├── V1__create_job_table.sql
│   │           └── V2__Add_job.sql
│   ├── play.plugins
│   └── routes

Please see flyway's documents about the naming convention for migration scripts.

http://flywaydb.org/documentation/migration/sql.html

Placeholders

Flyway can replace placeholders in Sql migrations. The default pattern is ${placeholder}. This can be configured using the placeholderPrefix and placeholderSuffix properties.

The placeholder prefix, suffix and key-value pairs can be specificed in application.conf, e.g.

db.default.migration.placeholderPrefix="$flyway{{{"
db.default.migration.placeholderSuffix="}}}"
db.default.migration.placeholders.foo="bar"
db.default.migration.placeholders.hoge="pupi"

This would cause

INSERT INTO USERS ($flyway{{{foo}}}) VALUES ('$flyway{{{hoge}}}')

to be rewritten to

INSERT INTO USERS (bar) VALUES ('pupi')

Enable/disable Validation

From flyway 3.0, validate run before migrate by default. Set validateOnMigrate to false if you want to disable this.

db.${dbName}.migration.validateOnMigrate=false // true by default

Dev

screenshot

For existing schema, Flyway has a option called 'initOnMigrate'. This option is enabled when -Ddb.${dbName}.migration.initOnMigrate=true. For example,

$ play -Ddb.default.migration.initOnMigrate=true

Of course, You can write this in your application.conf.

Manual migration is also supported. Click 'Other operations' or open /@flyway/${dbName} directly.

screenshot

Test

In Test mode, migration is done automatically.

Prod

In production mode, migration is done automatically if db.${dbName}.migration.auto is set to be true in application.conf. Otherwise it failed to start when migration is needed.

$ play -Ddb.default.migration.auto=true start

Callbacks

You can register callbacks during the migration process. For that use callbacks, and give an array with all the callbacks to run.

db.default.migration.callbacks=["db.MigrationLogCallback"]

Example application

seratch/devteam-app is using play-flyway. Maybe this is a good example.

Change Log

2.0.1

  • Supported new configuration key, db.default.username.

2.0.0

  • Play 2.4 support

License

  • Apache 2.0 License

About

Play modules for Flyway

License:Other


Languages

Language:Scala 98.8%Language:HTML 1.2%