hansenc / dropwizard-flyway

Addon bundle for Dropwizard to support Flyway for database migrations

Home Page:https://dropwizard.github.io/dropwizard-flyway/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Dropwizard Flyway

Build Status Coverage Status Maven Central

dropwizard-flyway is a set of commands using Flyway for database migrations in Dropwizard applications.

Usage

Just add the FlywayBundle to your Dropwizard application inside the Application#initialize method.

@Override
public void initialize(Bootstrap<MyConfiguration> bootstrap) {
    // ...
    bootstrap.addBundle(new FlywayBundle<MyConfiguration>() {
        @Override
        public DataSourceFactory getDataSourceFactory(MyConfiguration configuration) {
            return configuration.getDataSourceFactory();
        }
        
        @Override
        public FlywayFactory getFlywayFactory(MyConfiguration configuration) {
            return configuration.getFlywayFactory();
        }
    });
}

After that you can use one of the following Flyway commands:

Command Description
db migrate Migrates the database
db clean Drops all objects in the configured schemas
db info Prints the details and status information about all the migrations
db validate Validates the applied migrations against the ones available on the classpath
db init Creates and initializes the metadata table (existing database)
db repair Repairs the metadata table

The Flyway migrations must be accessible in the classpath under db/migration (or any other path configured with the locations parameter, see FlywayFactory).

Configuration

dropwizard-flyway is using the standard DataSourceFactory from dropwizard-db for configuring its DataSource.

Additionally you can override the following configuration settings of Flyway using FlywayFactory:

flyway:
  # The encoding of SQL migrations. (default: UTF-8) 
  encoding: UTF-8
  
  # The schemas managed by Flyway. (default: default schema of the connection)
  schemas:
  
  # The fully qualified class names of the callbacks for lifecycle notifications. (default: empty list)
  callbacks:
  
  # The name of the schema metadata table that will be used by Flyway. (default: flyway_schema_history)
  metaDataTableName: flyway_schema_history
  
  # The file name prefix for sql migrations (default: V)
  sqlMigrationPrefix: V
  
  # The file name separator for sql migrations (default: __)
  sqlMigrationSeparator: __
  
  # The file name suffixes for sql migrations (default: .sql)
  sqlMigrationSuffixes:
    - .sql
  
  # The prefix of every placeholder. (default: ${ )
  placeholderPrefix: ${
  
  # The suffix of every placeholder. (default: } )
  placeholderSuffix: }
  
  # The map of <placeholder, replacementValue> to apply to sql migration scripts. (default: empty map)
  placeholders:
  
  # Locations to scan recursively for migrations. (default: db/migration)
  locations:
    - db/migration
  
  # The fully qualified class names of the custom MigrationResolvers to be used in addition to the built-in ones for resolving Migrations to apply. (default: empty list)
  resolvers:
  
  # Allows migrations to be run "out of order". 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. (default: false)
  outOfOrder: false
  
  # The description to tag an existing schema with when executing baseline. (default: << Flyway Baseline >>)
  baselineDescription: "<< Flyway Baseline >>"
  
  # Whether to automatically call baseline when migrate is executed against a non-empty schema with no metadata table. (default: false)
  # 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!
  baselineOnMigrate: false
  
  # Whether to automatically call validate or not when running migrate. (default: true)
  validateOnMigrate: true
  
  # The version to tag an existing schema with when executing baseline. (default: 1)
  baselineVersion: 1
  
  # Whether to disabled clean. (default: false)
  # This is especially useful for production environments where running clean can be quite a career limiting move.
  cleanDisabled: false
  
  # Whether to group all pending migrations together in the same transaction when applying them
  # (only recommended for databases with support for DDL transactions).
  # true if migrations should be grouped. false if they should be applied individually instead. (default: false)
  group: false
  
  # Ignore future migrations when reading the schema history table. These are migrations that were performed by a
  # newer deployment of the application that are not yet available in this version.
  # true to continue normally and log a warning, false to fail fast with an exception. (default: true)
  ignoreFutureMigrations: true
  
  # Ignore ignored migrations when reading the schema history table. These are migrations that were added in between
  # already migrated migrations in this version.
  # true to continue normally, false to fail fast with an exception. (default: false)
  ignoreIgnoredMigrations: false
  
  # Ignore missing migrations when reading the schema history table. These are migrations that were performed by an
  # older deployment of the application that are no longer available in this version.
  # true to continue normally and log a warning, false to fail fast with an exception. (default: false)
  ignoreMissingMigrations: false
  
  # The username that will be recorded in the schema history table as having applied the migration.
  # <<blank>> for the current database user of the connection. (default: <<blank>>).
  installedBy:
  
  # Whether to allow mixing transactional and non-transactional statements within the same migration.
  # true if mixed migrations should be allowed. false if an error should be thrown instead. (default: false)
  mixed: false
  
  # Whether placeholders should be replaced. (default: true)
  placeholderReplacement: true
  
  # If set to true, default built-in callbacks (sql) are skipped and only custom callback as
  # defined by 'callbacks' are used. (default: false)
  skipDefaultCallbacks: false
  
  # If set to true, default built-in resolvers (jdbc, spring-jdbc and sql) are skipped and only custom resolvers as
  # defined by 'resolvers' are used. (default: false)
  skipDefaultResolvers: false
  
  #### COMMERCIAL FEATURES
  # (Flyway Pro and Flyway Enterprise only)
  
  # Whether to batch SQL statements when executing them. (default: false)
  batch: false
  
  # The file where to output the SQL statements of a migration dry run. If the file specified is in a non-existent
  # directory, Flyway will create all directories and parent directories as needed.
  # <<blank>> to execute the SQL statements directly against the database. (default: <<blank>>)
  #dryRunOutputFile:
  
  # Comma-separated list of the fully qualified class names of handlers for errors and warnings that occur during a
  # migration. This can be used to customize Flyway's behavior by for example throwing another runtime exception,
  # outputting a warning or suppressing the error instead of throwing a FlywayException.
  # ErrorHandlers are invoked in order until one reports to have successfully handled the errors or warnings.
  # If none do, or if none are present, Flyway falls back to its default handling of errors and warnings.
  # <<blank>> to use the default internal handler (default: <<blank>>)
  #errorHandlers:

  # Rules for the built-in error handler that lets you override specific SQL states and errors codes from error to
  # warning or from warning to error.
  # Each error override has the following format: STATE:12345:W. It is a 5 character SQL state, a colon, the SQL 
  # error code, a colon and finally the desired behavior that should override the initial one. The following 
  # behaviors are accepted: W to force a warning and E to force an error.
  # For example, to force Oracle stored procedure compilation issues to produce errors instead of warnings,
  # the following errorOverride can be used: 99999:17110:E
  #errorOverrides:
  
  # Whether to Flyway's support for Oracle SQL*Plus commands should be activated. (default: false)
  oracleSqlPlus: false
  
  # Whether to stream SQL migrations when executing them. (default: false)
  stream: false
  
  # Target version up to which Flyway should consider migrations.
  # The special value 'current' designates the current version of the schema. (default: <<latest version>>)
  #target:
  
  # The file name prefix for undo SQL migrations. (default: U)
  # Undo SQL migrations are responsible for undoing the effects of the versioned migration with the same version.
  # They have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
  # which using the defaults translates to U1.1__My_description.sql
  undoSqlMigrationPrefix: U

Maven Artifacts

This project is available on Maven Central. To add it to your project simply add the following dependencies to your pom.xml:

<dependency>
  <groupId>io.dropwizard.modules</groupId>
  <artifactId>dropwizard-flyway</artifactId>
  <version>1.3.0-5</version>
</dependency>

Support

Please file bug reports and feature requests in GitHub issues.

License

Copyright (c) 2014-2019 Jochen Schalanda, Dropwizard Team

This library is licensed under the Apache License, Version 2.0.

See http://www.apache.org/licenses/LICENSE-2.0.html or the LICENSE file in this repository for the full license text.

About

Addon bundle for Dropwizard to support Flyway for database migrations

https://dropwizard.github.io/dropwizard-flyway/

License:Apache License 2.0


Languages

Language:Java 100.0%