I have a setup in which migrations from previous scripts were removed.
The flyway configuration specifies that ignoreMissingMigrations is true.
However, Flyway fails with the following error
Validate failed: Detected applied migration not resolved locally: version_x
where version_x is the first version that was removed after baseline.
Why do I get this error although ignoreMissingMigrations is true ?
Note: Flyway version: 4.2.0
The problem comes from a special setup that Flyway is unable to handle correctly.
We have no newer applied migration, thus Flyway see this migration as a future migration instead of a missing migration. Thus the solution is to set ignoreFutureMigrations to true in addition to ignoreMissingMigrations.
Related
As far as i can tell, i can't see any other questions that ask this, so here goes:
I've been running the latest Symfony, for a side project, and encountered this error as i was writing the app. Nothing i do now fixes it, not even re-installing symfony, and i have no idea what the problem even is. I am getting the error:
The parameter "doctrine_migrations.dir_name" has a dependency on a
non-existent parameter "kernel.root_dir". Did you mean one of these:
"kernel.project_dir", "kernel.cache_dir", "kernel.logs_dir"?
It seems that you are using the undefined kernel.root_dir variable in your config/packages/doctrine_migrations.yaml config file.
You should replace it by kernel.project_dir:
# config/packages/doctrine_migrations.yaml
doctrine_migrations:
dir_name: '%kernel.project_dir%/src/Migrations'
See: https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html#configuration
Just to document the root cause.
Symfony 5 removed kernel.root_dir parameters. Doctrine Migrations Bundle uses it as default value for dir_name.
It's been discussed. See https://github.com/doctrine/DoctrineMigrationsBundle/issues/305 and https://github.com/doctrine/DoctrineMigrationsBundle/pull/295.
SOLUTION: right now (Symfony 5 and Migrations bundle 2.1.x), you should not delete doctrine_migrations.yaml. Leave it there with a dir_name that does not raise en error.
at this point i am assuming it is a symfony bug, so i will close this question. Thanks for everyone's help!
try
composer remove orm
composer require symfony/orm-pack
I have version v1, v2 in schema_version table.
I want to add version v1.1 in between.
How can i do it using cmd's with out manually dropping v2 and running flyway migrate once again?
Run with outOfOrder turned on; see the migrate docs.
Option: outOfOrder
Required: No
Default: false
Description: 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.
If you're running via the command line then do the following:
Add new migration as V1.1__description.sql or similar
Run flyway again with -outOfOrder true
Can Flyway be used to mix creation and migration scripts so that:
new installations run a schema creation script
existing installations run migration scripts, and never see the creation scripts of subsequent versions
?
E.g. given:
db/create/V1/V1__schema.sql
db/create/V2/V2__schema.sql
db/create/V3/V3__schema.sql
db/migration/V1/V1.1__migrateA.sql
db/migration/V2/V2.1__migrateB.sql
db/migration/V2/V2.2__migrateC.sql
An existing V1 installation would run the following to get to V3:
db/migration/V1/V1.1__migrateA.sql
db/migration/V2/V2.1__migrateB.sql
db/migration/V2/V2.2__migrateC.sql
It would never run the following, as these represent schema-only SQL produced by mysqldump:
db/create/V2/V2__schema.sql
db/create/V3/V3__schema.sql
A new V3 installation would run:
db/create/V3/V3__schema.sql
The above conflicts with the approach recommended by Upgrade scenario when using Flyway but is required as data is populated independently of the migration.
It looks like it should be possible to use flyway.locations to support this, but installations would always need to include the path to their creation script so that Flyway can see it.
The alternative appears to be to run the creation scripts outside of Flyway and set a baseline, but it would be nice if Flyway could manage everything.
In the end, I developed a tool to do this.
The tool has the latest schema in:
db/schema/schema.sql
and the migration scripts in:
db/migration/<version>/<version>.<sequence>__<JIRA issue>.sql
e.g.:
db/migration/V1/V1.1__JIRA-15.sql
db/migration/V2/V2.1__JIRA-12.sql
db/migration/V2/V2.2__JIRA-22.sql
db/migration/V3/V3.0__JIRA-34.sql
If the database has no tables, schema.sql is executed, and then flyway is baselined with the most recent version, as reported by Flyway's
MigrationInfoService.pending() method.
i.e. the last MigrationInfo element returned by pending() determines the version to pass to Flyway.setBaselineVersion() before invoking Flway.baseline()
e.g:
DbSupport support = DbSupportFactory.createDbSupport(connection, true);
Schema schema = support.getOriginalSchema();
if (schema.allTables().length == 0) {
Resource resource = new ClassPathResource("db/schema/schema.sql", getClass().getClassLoader());
SqlScript script = new SqlScript(resource.loadAsString("UTF-8"), support);
script.execute(support.getJdbcTemplate());
MigrationInfo[] pending = flyway.info().pending();
MigrationInfo version = pending.length > 0 ? pending[pending.length - 1] : null;
if (version != null) {
flyway.setBaselineVersion(version.getVersion());
flyway.setBaselineDescription(version.getDecription());
flyway.baseline();
}
}
This ensures that none of the migration scripts are invoked for newly created databases, but does mean that schema.sql must already contain all of the changes.
If the database has tables, but no Flyway information, it is baselined according to the detected schema version.
After upgrade of my project to symfony 2.8 I get the following error when I push the code to staging server.
[Symfony\Component\Config\Definition\Exception\InvalidConfigurationException]
Unrecognized option "firewall_name" under "hwi_oauth"
When i remove firewall_name option then I get an error that the option is required.
If someone provide some insight will be much appreciated.
You get this error now because when You was updating Symfony rest of dependencies was updated also.
This option was renamed to firewall_names to support multiple firewalls in this commit: https://github.com/hwi/HWIOAuthBundle/commit/9bdbc089ddffede12a5b575a441c4e0fa2ee9dd7 and released as part of 0.4.0 version.
Now it's value must be array. Example:
hwi_oauth:
firewall_names: [secured_area]
I'm using flyway with gradle, I've run one of the migrations manually inside the database console, I want to run flyway, but tell it to ignore one specific migration version in between all the others.
Can this be done?
You would have to hack it a bit to get it to work, so I don't recommend this approach, but it would work in a pinch.
I've only tested this with Maven, but I'm pretty sure it'd work with Gradle too.
Migrate up until the version before the one you applied manually
# Assuming you applied 01.002 manually
$ mvn flyway:migrate -Dflyway.target=01.001
Insert a row for the script you applied
-- Make sure these vals closely replicate those from other rows
insert into schema_version( installed_rank, version, description, type, script, checksum, installed_by, installed_on, execution_time, success)
values ( 2, '01.002', 'static_data', 'SQL', 'V01/V01.002__static_data.sql', null, 'username', current_timestamp, 0, true );
Repair the schema_version checksum
$ mvn flyway:repair
Apply the other migrations
$ mvn flyway:migrate -Dflyway.validateOnMigrate=false -Dflyway.outOfOrder=true
The two -D properties there may not be necessary, depending on whether you got the insert correct or not. Flyway may disagree with your script description, for example, even if the checksum is now correct.
Not Recommended, but if you still want to:
Run flywayMigrate, let the migration fail.
Manually, update the flyway meta table (success column) for that specific version of migration.
Run flywayMigrate again.
Done, flyway will now start with the next version of migration.
As of version 7, you can add it directly to your Maven or Grade file
Gradle - Skip
flyway {
skipExecutingMigrations = true
}
Maven - Skip
<configuration>
<skipExecutingMigrations>true</skipExecutingMigrations>
</configuration>
Documentation Reference Skip
Gradle - Cherry Pick
flyway {
cherryPick = '2.0'
}
Maven - Cherry Pick
<configuration>
<cherryPick>2.0</cherryPick>
</configuration>
Documentation Reference Cherry Pick