-
Fields Field Description org.flywaydb.gradle.FlywayExtension.ignoreFutureMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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. (default:true
)Also configurable with Gradle or System Property: ${flyway.ignoreFutureMigrations}
org.flywaydb.gradle.FlywayExtension.ignoreIgnoredMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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.(default:false
)Also configurable with Gradle or System Property: ${flyway.ignoreIgnoredMigrations}
org.flywaydb.gradle.FlywayExtension.ignoreMissingMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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.(default:false
)Also configurable with Gradle or System Property: ${flyway.ignoreMissingMigrations}
org.flywaydb.gradle.FlywayExtension.ignorePendingMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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. (default:false
)Also configurable with Gradle or System Property: ${flyway.ignorePendingMigrations}
org.flywaydb.gradle.task.AbstractFlywayTask.ignoreFutureMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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. (default:true
)Also configurable with Gradle or System Property: ${flyway.ignoreFutureMigrations}
org.flywaydb.gradle.task.AbstractFlywayTask.ignoreIgnoredMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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.(default:false
)Also configurable with Gradle or System Property: ${flyway.ignoreIgnoredMigrations}
org.flywaydb.gradle.task.AbstractFlywayTask.ignoreMissingMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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.(default:false
)Also configurable with Gradle or System Property: ${flyway.ignoreMissingMigrations}
org.flywaydb.gradle.task.AbstractFlywayTask.ignorePendingMigrations Will remove in Flyway V9. UseignoreMigrationPatterns
instead. 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. (default:false
)Also configurable with Gradle or System Property: ${flyway.ignorePendingMigrations}