Package org.flywaydb.core.api.configuration

Class FluentConfiguration

  • All Implemented Interfaces:
    Configuration
    public class FluentConfiguration
extends java.lang.Object
implements Configuration
    Fluent configuration for Flyway. This is the preferred means of configuring the Flyway API.

    This configuration can be passed to Flyway using the new Flyway(Configuration) constructor.

    • Constructor Detail

      • FluentConfiguration

        public FluentConfiguration()
        Creates a new default configuration.

      • FluentConfiguration

        public FluentConfiguration​(java.lang.ClassLoader classLoader)
        Creates a new default configuration with this class loader.
        Parameters:
        classLoader - The ClassLoader to use for loading migrations, resolvers, etc from the classpath. (default: Thread.currentThread().getContextClassLoader() )

    • Method Detail

      • load

        public Flyway load()
        Loads this configuration into a new Flyway instance.
        Returns:
        The new fully-configured Flyway instance.

      • configuration

        public FluentConfiguration configuration​(Configuration configuration)
        Configure with the same values as this existing configuration.
        Parameters:
        configuration - The configuration to use.

      • getLocations

        public Location[] getLocations()
        Description copied from interface: Configuration
        Retrieves the 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, may only contain SQL migrations and are only scanned recursively down non-hidden directories.

        Specified by:
        getLocations in interface Configuration
        Returns:
        Locations to scan recursively for migrations. (default: classpath:db/migration)

      • getEncoding

        public java.nio.charset.Charset getEncoding()
        Description copied from interface: Configuration
        Retrieves the encoding of Sql migrations.
        Specified by:
        getEncoding in interface Configuration
        Returns:
        The encoding of Sql migrations. (default: UTF-8)

      • getSchemas

        public java.lang.String[] getSchemas()
        Description copied from interface: Configuration
        Retrieves the schemas managed by Flyway. These schema names are case-sensitive.

        Consequences:

        • Flyway will automatically attempt to create all these schemas, unless the first one already exists.
        • 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 schema history table.
        • The schemas will be cleaned in the order of this list.
        • If Flyway created them, the schemas themselves will as be dropped when cleaning.
        Specified by:
        getSchemas in interface Configuration
        Returns:
        The schemas managed by Flyway. (default: The default schema for the database connection)

      • getTable

        public java.lang.String getTable()
        Description copied from interface: Configuration

        Retrieves the name of the schema history table that will be used by Flyway.

        By default (single-schema mode) the schema history 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 schema history table is placed in the first schema of the list.

        Specified by:
        getTable in interface Configuration
        Returns:
        The name of the schema history table that will be used by Flyway. (default: flyway_schema_history)

      • getTablespace

        public java.lang.String getTablespace()
        Description copied from interface: Configuration

        Retrieves the tablespace where to create the schema history table that will be used by Flyway.

        This setting is only relevant for databases that do support the notion of tablespaces. It's value is simply ignored for all others.

        Specified by:
        getTablespace in interface Configuration
        Returns:
        The tablespace where to create the schema history table that will be used by Flyway. (default: The default tablespace for the database connection)

      • getTarget

        public MigrationVersion getTarget()
        Description copied from interface: Configuration
        Gets the target version up to which Flyway should consider migrations. Migrations with a higher version number will be ignored. Special values:
        • current: designates the current version of the schema
        • latest: the latest version of the schema, as defined by the migration with the highest version
        Defaults to latest.
        Specified by:
        getTarget in interface Configuration
        Returns:
        The target version up to which Flyway should consider migrations. Defaults to latest

      • isPlaceholderReplacement

        public boolean isPlaceholderReplacement()
        Description copied from interface: Configuration
        Checks whether placeholders should be replaced.
        Specified by:
        isPlaceholderReplacement in interface Configuration
        Returns:
        Whether placeholders should be replaced. (default: true)

      • getPlaceholders

        public java.util.Map<java.lang.String,​java.lang.String> getPlaceholders()
        Description copied from interface: Configuration
        Retrieves the map of <placeholder, replacementValue> to apply to sql migration scripts.
        Specified by:
        getPlaceholders in interface Configuration
        Returns:
        The map of <placeholder, replacementValue> to apply to sql migration scripts.

      • getPlaceholderPrefix

        public java.lang.String getPlaceholderPrefix()
        Description copied from interface: Configuration
        Retrieves the prefix of every placeholder.
        Specified by:
        getPlaceholderPrefix in interface Configuration
        Returns:
        The prefix of every placeholder. (default: ${ )

      • getPlaceholderSuffix

        public java.lang.String getPlaceholderSuffix()
        Description copied from interface: Configuration
        Retrieves the suffix of every placeholder.
        Specified by:
        getPlaceholderSuffix in interface Configuration
        Returns:
        The suffix of every placeholder. (default: } )

      • getSqlMigrationPrefix

        public java.lang.String getSqlMigrationPrefix()
        Description copied from interface: Configuration
        The file name prefix for versioned SQL migrations.

        Versioned SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , which using the defaults translates to V1.1__My_description.sql

        Specified by:
        getSqlMigrationPrefix in interface Configuration
        Returns:
        The file name prefix for sql migrations. (default: V)

      • getRepeatableSqlMigrationPrefix

        public java.lang.String getRepeatableSqlMigrationPrefix()
        Description copied from interface: Configuration
        Retrieves the file name prefix for repeatable SQL migrations.

        Repeatable SQL migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix , which using the defaults translates to R__My_description.sql

        Specified by:
        getRepeatableSqlMigrationPrefix in interface Configuration
        Returns:
        The file name prefix for repeatable sql migrations. (default: R)

      • getSqlMigrationSeparator

        public java.lang.String getSqlMigrationSeparator()
        Description copied from interface: Configuration
        Retrieves the file name separator for sql migrations.

        Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , which using the defaults translates to V1_1__My_description.sql

        Specified by:
        getSqlMigrationSeparator in interface Configuration
        Returns:
        The file name separator for sql migrations. (default: __)

      • getSqlMigrationSuffixes

        public java.lang.String[] getSqlMigrationSuffixes()
        Description copied from interface: Configuration
        The file name suffixes 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

        Multiple suffixes (like .sql,.pkg,.pkb) can be specified for easier compatibility with other tools such as editors with specific file associations.

        Specified by:
        getSqlMigrationSuffixes in interface Configuration
        Returns:
        The file name suffixes for SQL migrations.

      • getJavaMigrations

        public JavaMigration[] getJavaMigrations()
        Description copied from interface: Configuration
        The manually added Java-based migrations. These are not Java-based migrations discovered through classpath scanning and instantiated by Flyway. Instead these are manually added instances of JavaMigration. This is particularly useful when working with a dependency injection container, where you may want the DI container to instantiate the class and wire up its dependencies for you.
        Specified by:
        getJavaMigrations in interface Configuration
        Returns:
        The manually added Java-based migrations. An empty array if none. (default: none)

      • isIgnoreMissingMigrations

        public boolean isIgnoreMissingMigrations()
        Description copied from interface: Configuration
        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. For example: we have migrations available on the classpath with versions 1.0 and 3.0. The schema history table indicates that a migration with version 2.0 (unknown to us) has also been applied. Instead of bombing out (fail fast) with an exception, a warning is logged and Flyway continues normally. This is useful for situations where one must be able to deploy a newer version of the application even though it doesn't contain migrations included with an older one anymore. Note that if the most recently applied migration is removed, Flyway has no way to know it is missing and will mark it as future instead.
        Specified by:
        isIgnoreMissingMigrations in interface Configuration
        Returns:
        true to continue normally and log a warning, false to fail fast with an exception. (default: false)

      • isIgnoreIgnoredMigrations

        public boolean isIgnoreIgnoredMigrations()
        Description copied from interface: Configuration
        Ignore ignored migrations when reading the schema history table. These are migrations that were added in between already migrated migrations in this version. For example: we have migrations available on the classpath with versions from 1.0 to 3.0. The schema history table indicates that version 1 was finished on 1.0.15, and the next one was 2.0.0. But with the next release a new migration was added to version 1: 1.0.16. Such scenario is ignored by migrate command, but by default is rejected by validate. When ignoreIgnoredMigrations is enabled, such case will not be reported by validate command. This is useful for situations where one must be able to deliver complete set of migrations in a delivery package for multiple versions of the product, and allows for further development of older versions.
        Specified by:
        isIgnoreIgnoredMigrations in interface Configuration
        Returns:
        true to continue normally, false to fail fast with an exception. (default: false)

      • isIgnorePendingMigrations

        public boolean isIgnorePendingMigrations()
        Description copied from interface: Configuration
        Ignore pending migrations when reading the schema history table. These are migrations that are available but have not yet been applied. This can be useful for verifying that in-development migration changes don't contain any validation-breaking changes of migrations that have already been applied to a production environment, e.g. as part of a CI/CD process, without failing because of the existence of new migration versions.
        Specified by:
        isIgnorePendingMigrations in interface Configuration
        Returns:
        true to continue normally, false to fail fast with an exception. (default: false)

      • isIgnoreFutureMigrations

        public boolean isIgnoreFutureMigrations()
        Description copied from interface: Configuration
        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. For example: we have migrations available on the classpath up to version 3.0. The schema history table indicates that a migration to version 4.0 (unknown to us) has already been applied. Instead of bombing out (fail fast) with an exception, a warning is logged and Flyway continues normally. This is useful for situations where one must be able to redeploy an older version of the application after the database has been migrated by a newer one.
        Specified by:
        isIgnoreFutureMigrations in interface Configuration
        Returns:
        true to continue normally and log a warning, false to fail fast with an exception. (default: true)

      • isValidateOnMigrate

        public boolean isValidateOnMigrate()
        Description copied from interface: Configuration
        Whether to automatically call validate or not when running migrate.
        Specified by:
        isValidateOnMigrate in interface Configuration
        Returns:
        true if validate should be called. false if not. (default: true)

      • isCleanOnValidationError

        public boolean isCleanOnValidationError()
        Description copied from interface: Configuration
        Whether to automatically call clean or not when a validation error occurs.

        This is exclusively intended as a convenience for development. even though 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 !

        Specified by:
        isCleanOnValidationError in interface Configuration
        Returns:
        true if clean should be called. false if not. (default: false)

      • isCleanDisabled

        public boolean isCleanDisabled()
        Description copied from interface: Configuration
        Whether to disable clean.

        This is especially useful for production environments where running clean can be quite a career limiting move.

        Specified by:
        isCleanDisabled in interface Configuration
        Returns:
        true to disabled clean. false to leave it enabled. (default: false)

      • getBaselineVersion

        public MigrationVersion getBaselineVersion()
        Description copied from interface: Configuration
        Retrieves the version to tag an existing schema with when executing baseline.
        Specified by:
        getBaselineVersion in interface Configuration
        Returns:
        The version to tag an existing schema with when executing baseline. (default: 1)

      • getBaselineDescription

        public java.lang.String getBaselineDescription()
        Description copied from interface: Configuration
        Retrieves the description to tag an existing schema with when executing baseline.
        Specified by:
        getBaselineDescription in interface Configuration
        Returns:
        The description to tag an existing schema with when executing baseline. (default: << Flyway Baseline >>)

      • isBaselineOnMigrate

        public boolean isBaselineOnMigrate()
        Description copied from interface: Configuration

        Whether to automatically call baseline when migrate is executed against a non-empty schema with no schema history 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!

        Specified by:
        isBaselineOnMigrate in interface Configuration
        Returns:
        true if baseline should be called on migrate for non-empty schemas, false if not. (default: false)

      • isOutOfOrder

        public boolean isOutOfOrder()
        Description copied from interface: Configuration
        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.

        Specified by:
        isOutOfOrder in interface Configuration
        Returns:
        true if outOfOrder migrations should be applied, false if not. (default: false)

      • getResolvers

        public MigrationResolver[] getResolvers()
        Description copied from interface: Configuration
        Retrieves the The custom MigrationResolvers to be used in addition to the built-in ones for resolving Migrations to apply.
        Specified by:
        getResolvers in interface Configuration
        Returns:
        The custom MigrationResolvers to be used in addition to the built-in ones for resolving Migrations to apply. An empty array if none. (default: none)

      • isSkipDefaultResolvers

        public boolean isSkipDefaultResolvers()
        Description copied from interface: Configuration
        Whether Flyway should skip the default resolvers. If true, only custom resolvers are used.
        Specified by:
        isSkipDefaultResolvers in interface Configuration
        Returns:
        Whether default built-in resolvers should be skipped. (default: false)

      • getDataSource

        public javax.sql.DataSource getDataSource()
        Description copied from interface: Configuration
        Retrieves the dataSource to use to access the database. Must have the necessary privileges to execute ddl.
        Specified by:
        getDataSource in interface Configuration
        Returns:
        The dataSource to use to access the database. Must have the necessary privileges to execute ddl.

      • getConnectRetries

        public int getConnectRetries()
        Description copied from interface: Configuration
        The maximum number of retries when attempting to connect to the database. After each failed attempt, Flyway will wait 1 second before attempting to connect again, up to the maximum number of times specified by connectRetries.
        Specified by:
        getConnectRetries in interface Configuration
        Returns:
        The maximum number of retries when attempting to connect to the database. (default: 0)

      • getInitSql

        public java.lang.String getInitSql()
        Description copied from interface: Configuration
        The SQL statements to run to initialize a new database connection immediately after opening it.
        Specified by:
        getInitSql in interface Configuration
        Returns:
        The SQL statements. (default: null)

      • getClassLoader

        public java.lang.ClassLoader getClassLoader()
        Description copied from interface: Configuration
        Retrieves the ClassLoader to use for loading migrations, resolvers, etc from the classpath.
        Specified by:
        getClassLoader in interface Configuration
        Returns:
        The ClassLoader to use for loading migrations, resolvers, etc from the classpath. (default: Thread.currentThread().getContextClassLoader() )

      • isMixed

        public boolean isMixed()
        Description copied from interface: Configuration
        Whether to allow mixing transactional and non-transactional statements within the same migration. Enabling this automatically causes the entire affected migration to be run without a transaction.

        Note that this is only applicable for PostgreSQL, Aurora PostgreSQL, SQL Server and SQLite which all have statements that do not run at all within a transaction.

        This is not to be confused with implicit transaction, as they occur in MySQL or Oracle, where even though a DDL statement was run within within a transaction, the database will issue an implicit commit before and after its execution.

        Specified by:
        isMixed in interface Configuration
        Returns:
        true if mixed migrations should be allowed. false if an error should be thrown instead. (default: false)

      • getInstalledBy

        public java.lang.String getInstalledBy()
        Description copied from interface: Configuration
        The username that will be recorded in the schema history table as having applied the migration.
        Specified by:
        getInstalledBy in interface Configuration
        Returns:
        The username or null for the current database user of the connection. (default: null).

      • isGroup

        public boolean isGroup()
        Description copied from interface: Configuration
        Whether to group all pending migrations together in the same transaction when applying them (only recommended for databases with support for DDL transactions).
        Specified by:
        isGroup in interface Configuration
        Returns:
        true if migrations should be grouped. false if they should be applied individually instead. (default: false)

      • getErrorOverrides

        public java.lang.String[] getErrorOverrides()
        Description copied from interface: Configuration
        Rules for the built-in error handler that let you override specific SQL states and errors codes in order to force specific errors or warnings to be treated as debug messages, info messages, warnings or errors.

        Each error override has the following format: STATE:12345:W. It is a 5 character SQL state (or * to match all SQL states), a colon, the SQL error code (or * to match all SQL error codes), a colon and finally the desired behavior that should override the initial one.

        The following behaviors are accepted:

        • D to force a debug message
        • D- to force a debug message, but do not show the original sql state and error code
        • I to force an info message
        • I- to force an info message, but do not show the original sql state and error code
        • W to force a warning
        • W- to force a warning, but do not show the original sql state and error code
        • E to force an error
        • E- to force an error, but do not show the original sql state and error code

        Example 1: to force Oracle stored procedure compilation issues to produce errors instead of warnings, the following errorOverride can be used: 99999:17110:E

        Example 2: to force SQL Server PRINT messages to be displayed as info messages (without SQL state and error code details) instead of warnings, the following errorOverride can be used: S0001:0:I-

        Example 3: to force all errors with SQL error code 123 to be treated as warnings instead, the following errorOverride can be used: *:123:W

        Flyway Pro and Flyway Enterprise only

        Specified by:
        getErrorOverrides in interface Configuration
        Returns:
        The ErrorOverrides or an empty array if none are defined. (default: none)

      • getDryRunOutput

        public java.io.OutputStream getDryRunOutput()
        Description copied from interface: Configuration
        The stream where to output the SQL statements of a migration dry run. null if the SQL statements are executed against the database directly.

        Flyway Pro and Flyway Enterprise only

        Specified by:
        getDryRunOutput in interface Configuration
        Returns:
        The stream or null if the SQL statements are executed against the database directly.

      • isStream

        public boolean isStream()
        Description copied from interface: Configuration
        Whether to stream SQL migrations when executing them. Streaming doesn't load the entire migration in memory at once. Instead each statement is loaded individually. This is particularly useful for very large SQL migrations composed of multiple MB or even GB of reference data, as this dramatically reduces Flyway's memory consumption.

        Flyway Pro and Flyway Enterprise only

        Specified by:
        isStream in interface Configuration
        Returns:
        true to stream SQL migrations. false to fully loaded them in memory instead. (default: false)

      • isBatch

        public boolean isBatch()
        Description copied from interface: Configuration
        Whether to batch SQL statements when executing them. Batching can save up to 99 percent of network roundtrips by sending up to 100 statements at once over the network to the database, instead of sending each statement individually. This is particularly useful for very large SQL migrations composed of multiple MB or even GB of reference data, as this can dramatically reduce the network overhead. This is supported for INSERT, UPDATE, DELETE, MERGE and UPSERT statements. All other statements are automatically executed without batching.

        Flyway Pro and Flyway Enterprise only

        Specified by:
        isBatch in interface Configuration
        Returns:
        true to batch SQL statements. false to execute them individually instead. (default: false)

      • isOracleSqlplus

        public boolean isOracleSqlplus()
        Description copied from interface: Configuration
        Whether to Flyway's support for Oracle SQL*Plus commands should be activated.

        Flyway Pro and Flyway Enterprise only

        Specified by:
        isOracleSqlplus in interface Configuration
        Returns:
        true to active SQL*Plus support. false to fail fast instead. (default: false)

      • isOracleSqlplusWarn

        public boolean isOracleSqlplusWarn()
        Description copied from interface: Configuration
        Whether Flyway should issue a warning instead of an error whenever it encounters an Oracle SQL*Plus statement it doesn't yet support.

        Flyway Pro and Flyway Enterprise only

        Specified by:
        isOracleSqlplusWarn in interface Configuration
        Returns:
        true to issue a warning. false to fail fast instead. (default: false)

      • getLicenseKey

        public java.lang.String getLicenseKey()
        Description copied from interface: Configuration
        Your Flyway license key (FL01...). Not yet a Flyway Pro or Enterprise Edition customer? Request your Flyway trial license key to try out Flyway Pro and Enterprise Edition features free for 30 days.

        Flyway Pro and Flyway Enterprise only

        Specified by:
        getLicenseKey in interface Configuration
        Returns:
        Your Flyway license key.

      • outputQueryResults

        public boolean outputQueryResults()
        Description copied from interface: Configuration
        Whether Flyway should output a table with the results of queries when executing migrations.

        Flyway Pro and Flyway Enterprise only

        Specified by:
        outputQueryResults in interface Configuration
        Returns:
        true to output the results table (default: true)

      • dryRunOutput

        public FluentConfiguration dryRunOutput​(java.io.OutputStream dryRunOutput)
        Sets the stream where to output the SQL statements of a migration dry run. null to execute the SQL statements directly against the database. The stream when be closing when Flyway finishes writing the output.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        dryRunOutput - The output file or null to execute the SQL statements directly against the database.

      • dryRunOutput

        public FluentConfiguration dryRunOutput​(java.io.File dryRunOutput)
        Sets the file where to output the SQL statements of a migration dry run. null to execute the SQL statements directly against the database. If the file specified is in a non-existent directory, Flyway will create all directories and parent directories as needed.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        dryRunOutput - The output file or null to execute the SQL statements directly against the database.

      • dryRunOutput

        public FluentConfiguration dryRunOutput​(java.lang.String dryRunOutputFileName)
        Sets the file where to output the SQL statements of a migration dry run. null to execute the SQL statements directly against the database. If the file specified is in a non-existent directory, Flyway will create all directories and parent directories as needed.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        dryRunOutputFileName - The name of the output file or null to execute the SQL statements directly against the database.

      • errorOverrides

        public FluentConfiguration errorOverrides​(java.lang.String... errorOverrides)
        Rules for the built-in error handler that let you override specific SQL states and errors codes in order to force specific errors or warnings to be treated as debug messages, info messages, warnings or errors.

        Each error override has the following format: STATE:12345:W. It is a 5 character SQL state (or * to match all SQL states), a colon, the SQL error code (or * to match all SQL error codes), a colon and finally the desired behavior that should override the initial one.

        The following behaviors are accepted:

        • D to force a debug message
        • D- to force a debug message, but do not show the original sql state and error code
        • I to force an info message
        • I- to force an info message, but do not show the original sql state and error code
        • W to force a warning
        • W- to force a warning, but do not show the original sql state and error code
        • E to force an error
        • E- to force an error, but do not show the original sql state and error code

        Example 1: to force Oracle stored procedure compilation issues to produce errors instead of warnings, the following errorOverride can be used: 99999:17110:E

        Example 2: to force SQL Server PRINT messages to be displayed as info messages (without SQL state and error code details) instead of warnings, the following errorOverride can be used: S0001:0:I-

        Example 3: to force all errors with SQL error code 123 to be treated as warnings instead, the following errorOverride can be used: *:123:W

        Flyway Pro and Flyway Enterprise only

        Parameters:
        errorOverrides - The ErrorOverrides or an empty array if none are defined. (default: none)

      • group

        public FluentConfiguration group​(boolean group)
        Whether to group all pending migrations together in the same transaction when applying them (only recommended for databases with support for DDL transactions).
        Parameters:
        group - true if migrations should be grouped. false if they should be applied individually instead. (default: false)

      • installedBy

        public FluentConfiguration installedBy​(java.lang.String installedBy)
        The username that will be recorded in the schema history table as having applied the migration.
        Parameters:
        installedBy - The username or null for the current database user of the connection. (default: null).

      • mixed

        public FluentConfiguration mixed​(boolean mixed)
        Whether to allow mixing transactional and non-transactional statements within the same migration. Enabling this automatically causes the entire affected migration to be run without a transaction.

        Note that this is only applicable for PostgreSQL, Aurora PostgreSQL, SQL Server and SQLite which all have statements that do not run at all within a transaction.

        This is not to be confused with implicit transaction, as they occur in MySQL or Oracle, where even though a DDL statement was run within within a transaction, the database will issue an implicit commit before and after its execution.

        Parameters:
        mixed - true if mixed migrations should be allowed. false if an error should be thrown instead. (default: false)

      • ignoreMissingMigrations

        public FluentConfiguration ignoreMissingMigrations​(boolean ignoreMissingMigrations)
        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. For example: we have migrations available on the classpath with versions 1.0 and 3.0. The schema history table indicates that a migration with version 2.0 (unknown to us) has also been applied. Instead of bombing out (fail fast) with an exception, a warning is logged and Flyway continues normally. This is useful for situations where one must be able to deploy a newer version of the application even though it doesn't contain migrations included with an older one anymore. Note that if the most recently applied migration is removed, Flyway has no way to know it is missing and will mark it as future instead.
        Parameters:
        ignoreMissingMigrations - true to continue normally and log a warning, false to fail fast with an exception. (default: false)

      • ignoreIgnoredMigrations

        public FluentConfiguration ignoreIgnoredMigrations​(boolean ignoreIgnoredMigrations)
        Ignore ignored migrations when reading the schema history table. These are migrations that were added in between already migrated migrations in this version. For example: we have migrations available on the classpath with versions from 1.0 to 3.0. The schema history table indicates that version 1 was finished on 1.0.15, and the next one was 2.0.0. But with the next release a new migration was added to version 1: 1.0.16. Such scenario is ignored by migrate command, but by default is rejected by validate. When ignoreIgnoredMigrations is enabled, such case will not be reported by validate command. This is useful for situations where one must be able to deliver complete set of migrations in a delivery package for multiple versions of the product, and allows for further development of older versions.
        Parameters:
        ignoreIgnoredMigrations - true to continue normally, false to fail fast with an exception. (default: false)

      • ignorePendingMigrations

        public FluentConfiguration ignorePendingMigrations​(boolean ignorePendingMigrations)
        Ignore pending migrations when reading the schema history table. These are migrations that are available but have not yet been applied. This can be useful for verifying that in-development migration changes don't contain any validation-breaking changes of migrations that have already been applied to a production environment, e.g. as part of a CI/CD process, without failing because of the existence of new migration versions.
        Parameters:
        ignorePendingMigrations - true to continue normally, false to fail fast with an exception. (default: false)

      • ignoreFutureMigrations

        public FluentConfiguration ignoreFutureMigrations​(boolean ignoreFutureMigrations)
        Whether to 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. For example: we have migrations available on the classpath up to version 3.0. The schema history table indicates that a migration to version 4.0 (unknown to us) has already been applied. Instead of bombing out (fail fast) with an exception, a warning is logged and Flyway continues normally. This is useful for situations where one must be able to redeploy an older version of the application after the database has been migrated by a newer one.
        Parameters:
        ignoreFutureMigrations - true to continue normally and log a warning, false to fail fast with an exception. (default: true)

      • validateOnMigrate

        public FluentConfiguration validateOnMigrate​(boolean validateOnMigrate)
        Whether to automatically call validate or not when running migrate.
        Parameters:
        validateOnMigrate - true if validate should be called. false if not. (default: true)

      • cleanOnValidationError

        public FluentConfiguration cleanOnValidationError​(boolean cleanOnValidationError)
        Whether to automatically call clean or not when a validation error occurs.

        This is exclusively intended as a convenience for development. even though 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 !

        Parameters:
        cleanOnValidationError - true if clean should be called. false if not. (default: false)

      • cleanDisabled

        public FluentConfiguration cleanDisabled​(boolean cleanDisabled)
        Whether to disable clean.

        This is especially useful for production environments where running clean can be quite a career limiting move.

        Parameters:
        cleanDisabled - true to disabled clean. false to leave it enabled. (default: false)

      • locations

        public FluentConfiguration locations​(java.lang.String... locations)
        Sets the 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, may only contain SQL migrations and are only scanned recursively down non-hidden directories.

        Parameters:
        locations - Locations to scan recursively for migrations. (default: db/migration)

      • locations

        public FluentConfiguration locations​(Location... locations)
        Sets the 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, may only contain SQL migrations and are only scanned recursively down non-hidden directories.

        Parameters:
        locations - Locations to scan recursively for migrations. (default: db/migration)

      • encoding

        public FluentConfiguration encoding​(java.lang.String encoding)
        Sets the encoding of Sql migrations.
        Parameters:
        encoding - The encoding of Sql migrations. (default: UTF-8)

      • encoding

        public FluentConfiguration encoding​(java.nio.charset.Charset encoding)
        Sets the encoding of Sql migrations.
        Parameters:
        encoding - The encoding of Sql migrations. (default: UTF-8)

      • schemas

        public FluentConfiguration schemas​(java.lang.String... schemas)
        Sets the schemas managed by Flyway. These schema names are case-sensitive. (default: The default schema for the database connection)

        Consequences:

        • Flyway will automatically attempt to create all these schemas, unless the first one already exists.
        • 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 schema history table.
        • The schemas will be cleaned in the order of this list.
        • If Flyway created them, the schemas themselves will as be dropped when cleaning.
        Parameters:
        schemas - The schemas managed by Flyway. May not be null. Must contain at least one element.

      • table

        public FluentConfiguration table​(java.lang.String table)

        Sets the name of the schema history table that will be used by Flyway.

        By default (single-schema mode) the schema history 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 schema history table is placed in the first schema of the list.

        Parameters:
        table - The name of the schema history table that will be used by Flyway. (default: flyway_schema_history)

      • tablespace

        public FluentConfiguration tablespace​(java.lang.String tablespace)

        Sets the tablespace where to create the schema history table that will be used by Flyway.

        This setting is only relevant for databases that do support the notion of tablespaces. It's value is simply ignored for all others.

        Parameters:
        tablespace - The tablespace where to create the schema history table that will be used by Flyway. (default: The default tablespace for the database connection)

      • target

        public FluentConfiguration target​(MigrationVersion target)
        Sets the target version up to which Flyway should consider migrations. Migrations with a higher version number will be ignored. Special values:
        • current: designates the current version of the schema
        • latest: the latest version of the schema, as defined by the migration with the highest version
        Defaults to latest.

      • target

        public FluentConfiguration target​(java.lang.String target)
        Sets the target version up to which Flyway should consider migrations. Migrations with a higher version number will be ignored. Special values:
        • current: designates the current version of the schema
        • latest: the latest version of the schema, as defined by the migration with the highest version
        Defaults to latest.

      • placeholderReplacement

        public FluentConfiguration placeholderReplacement​(boolean placeholderReplacement)
        Sets whether placeholders should be replaced.
        Parameters:
        placeholderReplacement - Whether placeholders should be replaced. (default: true)

      • placeholders

        public FluentConfiguration placeholders​(java.util.Map<java.lang.String,​java.lang.String> placeholders)
        Sets the placeholders to replace in sql migration scripts.
        Parameters:
        placeholders - The map of <placeholder, replacementValue> to apply to sql migration scripts.

      • placeholderPrefix

        public FluentConfiguration placeholderPrefix​(java.lang.String placeholderPrefix)
        Sets the prefix of every placeholder.
        Parameters:
        placeholderPrefix - The prefix of every placeholder. (default: ${ )

      • placeholderSuffix

        public FluentConfiguration placeholderSuffix​(java.lang.String placeholderSuffix)
        Sets the suffix of every placeholder.
        Parameters:
        placeholderSuffix - The suffix of every placeholder. (default: } )

      • sqlMigrationPrefix

        public FluentConfiguration sqlMigrationPrefix​(java.lang.String sqlMigrationPrefix)
        Sets the file name prefix for sql migrations.

        Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , which using the defaults translates to V1_1__My_description.sql

        Parameters:
        sqlMigrationPrefix - The file name prefix for sql migrations (default: V)

      • getUndoSqlMigrationPrefix

        public java.lang.String getUndoSqlMigrationPrefix()
        Description copied from interface: Configuration
        The file name prefix for undo SQL migrations.

        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

        Flyway Pro and Flyway Enterprise only

        Specified by:
        getUndoSqlMigrationPrefix in interface Configuration
        Returns:
        The file name prefix for undo sql migrations. (default: U)

      • undoSqlMigrationPrefix

        public FluentConfiguration undoSqlMigrationPrefix​(java.lang.String undoSqlMigrationPrefix)
        Sets 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

        Flyway Pro and Flyway Enterprise only

        Parameters:
        undoSqlMigrationPrefix - The file name prefix for undo SQL migrations. (default: U)

      • repeatableSqlMigrationPrefix

        public FluentConfiguration repeatableSqlMigrationPrefix​(java.lang.String repeatableSqlMigrationPrefix)
        Sets the file name prefix for repeatable sql migrations.

        Repeatable sql migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix , which using the defaults translates to R__My_description.sql

        Parameters:
        repeatableSqlMigrationPrefix - The file name prefix for repeatable sql migrations (default: R)

      • sqlMigrationSeparator

        public FluentConfiguration sqlMigrationSeparator​(java.lang.String sqlMigrationSeparator)
        Sets the file name separator for sql migrations.

        Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , which using the defaults translates to V1_1__My_description.sql

        Parameters:
        sqlMigrationSeparator - The file name separator for sql migrations (default: __)

      • sqlMigrationSuffixes

        public FluentConfiguration sqlMigrationSuffixes​(java.lang.String... sqlMigrationSuffixes)
        The file name suffixes 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

        Multiple suffixes (like .sql,.pkg,.pkb) can be specified for easier compatibility with other tools such as editors with specific file associations.

        Parameters:
        sqlMigrationSuffixes - The file name suffixes for SQL migrations.

      • javaMigrations

        public FluentConfiguration javaMigrations​(JavaMigration... javaMigrations)
        The manually added Java-based migrations. These are not Java-based migrations discovered through classpath scanning and instantiated by Flyway. Instead these are manually added instances of JavaMigration. This is particularly useful when working with a dependency injection container, where you may want the DI container to instantiate the class and wire up its dependencies for you.
        Parameters:
        javaMigrations - The manually added Java-based migrations. An empty array if none. (default: none)

      • dataSource

        public FluentConfiguration dataSource​(javax.sql.DataSource dataSource)
        Sets the datasource to use. Must have the necessary privileges to execute ddl.
        Parameters:
        dataSource - The datasource to use. Must have the necessary privileges to execute ddl.

      • dataSource

        public FluentConfiguration dataSource​(java.lang.String url,
                                      java.lang.String user,
                                      java.lang.String password)
        Sets the datasource to use. Must have the necessary privileges to execute ddl.
        Parameters:
        url - The JDBC URL of the database.
        user - The user of the database.
        password - The password of the database.

      • connectRetries

        public FluentConfiguration connectRetries​(int connectRetries)
        The maximum number of retries when attempting to connect to the database. After each failed attempt, Flyway will wait 1 second before attempting to connect again, up to the maximum number of times specified by connectRetries.
        Parameters:
        connectRetries - The maximum number of retries (default: 0).

      • initSql

        public FluentConfiguration initSql​(java.lang.String initSql)
        The SQL statements to run to initialize a new database connection immediately after opening it.
        Parameters:
        initSql - The SQL statements. (default: null)

      • baselineVersion

        public FluentConfiguration baselineVersion​(MigrationVersion baselineVersion)
        Sets the version to tag an existing schema with when executing baseline.
        Parameters:
        baselineVersion - The version to tag an existing schema with when executing baseline. (default: 1)

      • baselineVersion

        public FluentConfiguration baselineVersion​(java.lang.String baselineVersion)
        Sets the version to tag an existing schema with when executing baseline.
        Parameters:
        baselineVersion - The version to tag an existing schema with when executing baseline. (default: 1)

      • baselineDescription

        public FluentConfiguration baselineDescription​(java.lang.String baselineDescription)
        Sets the description to tag an existing schema with when executing baseline.
        Parameters:
        baselineDescription - The description to tag an existing schema with when executing baseline. (default: << Flyway Baseline >>)

      • baselineOnMigrate

        public FluentConfiguration baselineOnMigrate​(boolean baselineOnMigrate)

        Whether to automatically call baseline when migrate is executed against a non-empty schema with no schema history table. This schema will then be baselined 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!

        Parameters:
        baselineOnMigrate - true if baseline should be called on migrate for non-empty schemas, false if not. (default: false)

      • outOfOrder

        public FluentConfiguration outOfOrder​(boolean outOfOrder)
        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.

        Parameters:
        outOfOrder - true if outOfOrder migrations should be applied, false if not. (default: false)

      • getCallbacks

        public Callback[] getCallbacks()
        Gets the callbacks for lifecycle notifications.
        Specified by:
        getCallbacks in interface Configuration
        Returns:
        The callbacks for lifecycle notifications. An empty array if none. (default: none)

      • isSkipDefaultCallbacks

        public boolean isSkipDefaultCallbacks()
        Description copied from interface: Configuration
        Whether Flyway should skip the default callbacks. If true, only custom callbacks are used.
        Specified by:
        isSkipDefaultCallbacks in interface Configuration
        Returns:
        Whether default built-in callbacks should be skipped. (default: false)

      • callbacks

        public FluentConfiguration callbacks​(Callback... callbacks)
        Set the callbacks for lifecycle notifications.
        Parameters:
        callbacks - The callbacks for lifecycle notifications. (default: none)

      • callbacks

        public FluentConfiguration callbacks​(java.lang.String... callbacks)
        Set the callbacks for lifecycle notifications.
        Parameters:
        callbacks - The fully qualified class names of the callbacks for lifecycle notifications. (default: none)

      • skipDefaultCallbacks

        public FluentConfiguration skipDefaultCallbacks​(boolean skipDefaultCallbacks)
        Whether Flyway should skip the default callbacks. If true, only custom callbacks are used.
        Parameters:
        skipDefaultCallbacks - Whether default built-in callbacks should be skipped.

        (default: false)

      • resolvers

        public FluentConfiguration resolvers​(MigrationResolver... resolvers)
        Sets custom MigrationResolvers to be used in addition to the built-in ones for resolving Migrations to apply.
        Parameters:
        resolvers - The custom MigrationResolvers to be used in addition to the built-in ones for resolving Migrations to apply. (default: empty list)

      • resolvers

        public FluentConfiguration resolvers​(java.lang.String... resolvers)
        Sets custom MigrationResolvers to be used in addition to the built-in ones for resolving Migrations to apply.
        Parameters:
        resolvers - 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)

      • skipDefaultResolvers

        public FluentConfiguration skipDefaultResolvers​(boolean skipDefaultResolvers)
        Whether Flyway should skip the default resolvers. If true, only custom resolvers are used.
        Parameters:
        skipDefaultResolvers - Whether default built-in resolvers should be skipped.

        (default: false)

      • stream

        public FluentConfiguration stream​(boolean stream)
        Whether to stream SQL migrations when executing them. Streaming doesn't load the entire migration in memory at once. Instead each statement is loaded individually. This is particularly useful for very large SQL migrations composed of multiple MB or even GB of reference data, as this dramatically reduces Flyway's memory consumption.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        stream - true to stream SQL migrations. false to fully loaded them in memory instead. (default: false)

      • batch

        public FluentConfiguration batch​(boolean batch)
        Whether to batch SQL statements when executing them. Batching can save up to 99 percent of network roundtrips by sending up to 100 statements at once over the network to the database, instead of sending each statement individually. This is particularly useful for very large SQL migrations composed of multiple MB or even GB of reference data, as this can dramatically reduce the network overhead. This is supported for INSERT, UPDATE, DELETE, MERGE and UPSERT statements. All other statements are automatically executed without batching.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        batch - true to batch SQL statements. false to execute them individually instead. (default: false)

      • oracleSqlplus

        public FluentConfiguration oracleSqlplus​(boolean oracleSqlplus)
        Whether to Flyway's support for Oracle SQL*Plus commands should be activated.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        oracleSqlplus - true to active SQL*Plus support. false to fail fast instead. (default: false)

      • oracleSqlplusWarn

        public FluentConfiguration oracleSqlplusWarn​(boolean oracleSqlplusWarn)
        Whether Flyway should issue a warning instead of an error whenever it encounters an Oracle SQL*Plus statement it doesn't yet support.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        oracleSqlplusWarn - true to issue a warning. false to fail fast instead. (default: false)

      • licenseKey

        public FluentConfiguration licenseKey​(java.lang.String licenseKey)
        Your Flyway license key (FL01...). Not yet a Flyway Pro or Enterprise Edition customer? Request your Flyway trial license key to try out Flyway Pro and Enterprise Edition features free for 30 days.

        Flyway Pro and Flyway Enterprise only

        Parameters:
        licenseKey - Your Flyway license key.

      • configuration

        public FluentConfiguration configuration​(java.util.Properties properties)
        Configures Flyway with these properties. This overwrites any existing configuration. Property names are documented in the flyway maven plugin.

        To use a custom ClassLoader, setClassLoader() must be called prior to calling this method.

        Parameters:
        properties - Properties used for configuration.
        Throws:
        FlywayException - when the configuration failed.

      • configuration

        public FluentConfiguration configuration​(java.util.Map<java.lang.String,​java.lang.String> props)
        Configures Flyway with these properties. This overwrites any existing configuration. Property names are documented in the flyway maven plugin.

        To use a custom ClassLoader, it must be passed to the Flyway constructor prior to calling this method.

        Parameters:
        props - Properties used for configuration.
        Throws:
        FlywayException - when the configuration failed.