flyway
Evolve your database schema easily and reliably across all your instances.
This module run Flyway on startup and apply database migrations.
NOTE: This module depends on jdbc module to acquire a database connection.
dependency
<dependency>
<groupId>org.jooby</groupId>
<artifactId>jooby-flyway</artifactId>
<version>1.6.6</version>
</dependency>
usage
{
use(new Jdbc());
use(new Flywaydb());
}
If for any reason you need to maintain two or more databases:
{
use(new Jdbc("db1"));
use(new Flywaydb("db1"));
use(new Jdbc("db2"));
use(new Flywaydb("db2"));
}
migration scripts
Flyway looks for migration scripts at the db/migration
classpath location. We recommend to use Semantic versioning for naming the migration scripts:
v0.1.0_My_description.sql
v0.1.1_My_small_change.sql
commands
It is possible to run Flyway commands on startup, default command is: migrate
.
If you need to run multiple commands, set the flyway.run
property:
flyway.run = [clean, migrate, validate, info]
configuration
Configuration is done via application.conf
under the flyway.*
path. There are some defaults setting that you can see in the appendix section.
For more information, please visit the Flyway site.
flyway.conf
These are the default properties for flyway:
#
# Copyright 2010-2015 Axel Fontaine
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# If present, flyway will run as standalone on application startup. Otherwise, it depends on a DataSource provided by Jdbc module (usally)
# flyway.url=
# list of commands to run on startup
flyway.run = [migrate]
# Fully qualified classname of the jdbc driver (autodetected by default based on flyway.url)
# flyway.driver=
# User to use to connect to the database (default: <<null>>)
# flyway.user=
# Password to use to connect to the database (default: <<null>>)
# flyway.password=
# List of schemas managed by Flyway. These schema names are case-sensitive.
# (default: The default schema for the datasource connection)
# Consequences:
# - The first schema in the list will be automatically set as the default one during the migration.
# - The first schema in the list will also be the one containing the metadata table.
# - The schemas will be cleaned in the order of this list.
# flyway.schemas=
# Name of Flyway's metadata table (default: schema_version)
# By default (single-schema mode) the metadata table is placed in the default schema for the connection provided by the datasource.
# When the flyway.schemas property is set (multi-schema mode), the metadata table is placed in the first schema of the list.
# flyway.table=
# List of locations to scan recursively for migrations.
# The location type is determined by its prefix.
# Unprefixed locations or locations starting with classpath: point to a package on the classpath and may contain both sql and java-based migrations.
# Locations starting with filesystem: point to a directory on the filesystem and may only contain sql migrations.
flyway.locations= [db/migration]
# List of fully qualified class names of custom MigrationResolver to use for resolving migrations.
# flyway.resolvers=
# File name prefix for Sql migrations (default: v )
# Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# which using the defaults translates to V1_1__My_description.sql
flyway.sqlMigrationPrefix=v
# File name separator for Sql migrations (default: _)
# Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# which using the defaults translates to V1_1__My_description.sql
flyway.sqlMigrationSeparator=_
# File name suffix for Sql migrations (default: .sql)
# Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
# which using the defaults translates to V1_1__My_description.sql
# flyway.sqlMigrationSuffix=
# Encoding of Sql migrations (default: UTF-8)
flyway.encoding=${application.charset}
# Whether placeholders should be replaced. (default: true)
# flyway.placeholderReplacement=
# Placeholders to replace in Sql migrations
# flyway.placeholders.user=
# flyway.placeholders.my_other_placeholder=
# Prefix of every placeholder (default: ${ )
# flyway.placeholderPrefix=
# Suffix of every placeholder (default: } )
# flyway.placeholderSuffix=
# Target version up to which Flyway should consider migrations.
# The special value 'current' designates the current version of the schema. (default: <<latest version>>)
# flyway.target=
# Whether to automatically call validate or not when running migrate. (default: true)
# flyway.validateOnMigrate=
# Whether to automatically call clean or not when a validation error occurs. (default: false)
# This is exclusively intended as a convenience for development. Even tough we
# strongly recommend not to change migration scripts once they have been checked into SCM and run, this provides a
# way of dealing with this case in a smooth manner. The database will be wiped clean automatically, ensuring that
# the next migration will bring you back to the state checked into SCM.
# Warning ! Do not enable in production !
# flyway.cleanOnValidationError=
# The version to tag an existing schema with when executing baseline. (default: 1)
# flyway.baselineVersion=
# The description to tag an existing schema with when executing baseline. (default: << Flyway Baseline >>)
# flyway.baselineDescription=
# Whether to automatically call baseline when migrate is executed against a non-empty schema with no metadata table.
# This schema will then be initialized with the baselineVersion before executing the migrations.
# Only migrations above baselineVersion will then be applied.
# This is useful for initial Flyway production deployments on projects with an existing DB.
# Be careful when enabling this as it removes the safety net that ensures
# Flyway does not migrate the wrong database in case of a configuration mistake! (default: false)
# flyway.baselineOnMigrate=
# Allows migrations to be run "out of order" (default: false).
# If you already have versions 1 and 3 applied, and now a version 2 is found,
# it will be applied too instead of being ignored.
# flyway.outOfOrder=
# This allows you to tie in custom code and logic to the Flyway lifecycle notifications (default: empty).
# Set this to a comma-separated list of fully qualified FlywayCallback class name implementations
# flyway.callbacks=