Using ABv11, upgrading to v12 some time in near future.
Looking to cleanup the AB db ie. get rid of old objects that no longer serve a purpose prior to migration.
Thinking there should be a way to query the AB db for "last run timestamp" or maybe a tool to validate that the object/task still points to something at the other end on the production database. ie. a batch task no longer exists in the production tool but still has an AB task associated with it.
Is there any way to actually manage AB at a high level without having to go into each task/object and check individual TS's or reconcile against the target production objects?
Thanks.
Have researched different forums and the vendor site but nothingburger.
I am not using outOfOrder.
I would like to be able to add a migration script, that would not be the latest, (e.g. to bugfix an existing script, without changing that script).
I would like the new script to be run, as part of the normal ordering, on databases that haven't been migrated yet.
Any databases that are up to date (e.g. manually repaired) should ignore the new script.
From the documentation:
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.
This suggests that the new script will be ignored, but I get the error:
ERROR: Validate failed: Detected resolved migration not applied to database
Will the new script only be ignored if the db baseline is ahead of it?
Is this the expected behaviour?
If so, I guess my solution here is either to:
Use outOfOrder, and complicate all my scripts to be idempotent.
Baseline my db after every migration.
There is a pull request for this that will be merged in time for Flyway 5.1.0: https://github.com/flyway/flyway/pull/1866
Until then you also have the option to disable validation by setting validateOnMigrate to false.
after upgrading Flyway Maven plugin from 2.3 to 3.0 I get:
[ERROR] Failed to execute goal
org.flywaydb:flyway-maven-plugin:3.0:migrate (default-cli) on project
xxx: org.flywaydb.core.api.FlywayException: Validate failed. Found
differences between applied migrations and available migrations:
Migration Checksum mismatch for migration
V003__data_feed_sources_locations.sql: DB=942424992,
Classpath=1117634405 -> [Help 1]
Got a similar error on some other project.
If I downgrade back to 2.3 the migration runs ok. Does this has something to do with different platform encoding for calculating checksums?
Any workaround, or better yet, proper solution?
Flyway 3.0 changed the default of validateOnMigrate to true.
This is however a good thing, as in the spirit of fail fast, errors are discovered sooner.
In your case some scripts did change since they were applied, which is what Flyway is reporting.
You have two options:
suppress the error by setting validateOnMigrate to false (2.3 default behavior)
invoke Flyway.repair() to reallign the checksums
Reference
Flyway Repair
To add to Axel Fontaine's answer:
I was able to use mvn flyway:repair but I had to point the flyway.locations config property at the folder that contains my db migration scripts. Otherwise I would get the message "Repair of metadata table xyz.schema_version not necessary. No failed migration detected." like other folks mentioned.
I used mvn -Dflyway.locations=filesystem:<project dir>/src/main/resources/db/migrations flyway:repair and I saw the checksum updated in the metadata table, fixing my problem.
I found the easiest way to resolve this issue was to literally update the checksum in the schema table to the value flyway expected. I knew for a fact that my migration files had not changed and that the current state of the database was what it needed to be. I also did not want to spend time reading documentation and messing around with Flyway.repair() or other methods that could potentially mess things up even more. A simple sql update resolved it right away
First, it looks for checksum changes. These changes occur if we update migration files which are already applied to a db instance.
FlywayException: Validate failed: Migration checksum mismatch for migration version 18.2.6
-> Applied to database : 90181454
-> Resolved locally : 717386176
repair() method would fix up checksum issue by updating the flyway_schema_history table with local checksum value.
However, it would neglect updated statements in same migration file. So, new changes in same file would be neglected as there is already an entry for version in flyway_schema_history table. setValidateOnMigrate() method has no effect in this scenario. We should follow incremental approach, schema changes should be supplied through new files.
The issue happen right after I changed the V1_2__books.sql ddl file, There should be a better way to force flyway to recognize the new changes!!!
I tried to run mvn flyway:repair but it did not work, I ended up changing the schema url in the application.properties file [datasource.flyway.url] to books2
I removed the below files as well (books is my old schema name )
~ #~:rm books.mv.db
~ #~:rm -r books.trace.db
datasource.flyway.url=jdbc:h2:file:~/books2
datasource.flyway.username=sa
datasource.flyway.password=
datasource.flyway.driver-class-name=org.h2.Driver
I ran the application and BINGO :)
Just wanted to add, that in order for the checksum to be updated by repair. Flyway has to have access to the directory where all the migrations are. Otherwise flyway just goes about it's business and outputs
"Repair of failed migration in metadata table xyz.schema_version not necessary. No failed migration detected."
The checksum needs to be updated using the flyway repair command (run the Flyway command as stated in “Upgrade procedure” but replace “migrate” with “repair”).
I recommend you do not intrude directly to database, sql scripts, etc. It can be dangerous
Example:
./flyway repare -user=root -password=changeme -url=jdbc:mysql://localhost/mypath -table=my_flyway_schema_version_table -locations=filesystem:/mypath_sql_scripts
if you are running on local db u can delete the flyway_schema_history table
Invoke Flyway.repair() directly from configurations.
Add below bean to your configuration class or create a new class with #Congiguration annotation and add the below code.
#Bean
public FlywayMigrationStrategy repairFlyway() {
return flyway -> {
// repair each script's checksum
flyway.repair();
// before new migrations are executed
flyway.migrate();
};
}
There is yet another solution. You can drop your migration from schema_version table.
I recently added a scheduler job and program to my development schema. When I tried to refresh the schema, I did a flyway clean, and then a flyway migrate.
I got the following error:
ERROR: Found non-empty schema "TESTDATA" without metadata table! Use init() or set initOnMigrate to true to initialize the metadata table.
When I dropped the job and program by hand, I was then able to run migrate again.
I've been using flyway for a while, and it's always been very straightforward - but I'm not sure how to convince it to properly clean my schema, now that I have an overnight batch job.
Note: I see the option -initOnMigrate, but this causes me two problems:
I have a lot of batch files which would be sensitive to trying to add another runline option.
I use flyway both to update existing schemas and to refresh schemas from scratch. If I need to modify the job or program, I could only include initOnMigrate (and have it bomb on the update), or not include it, and have it bomb on refresh (my current problem).
Thank you
You can work around this by implementing FlywayCallback.afterClean() and do the cleanup yourself.
Also, please file an issue in the issue tracker so we can fix this in time for 3.1.
Here is how setup looks like:
ApplicationServer - GlassFish
Database Server - Oracle 10g2
Persistance Library - EclipseLink
Faces Framework - IceFaces
My Problem is that everytime I change the database connection the application/eclipselink stops working, failing to find the Persistance Unit.
After loosing a whole day trying to figure it out. I decided to delete all the information about connections and persistance units and use only one new created.
Building the project was not a problem, but running it I get an error, pointing that the there is a validationexception and a persistance unit with a given name was not found. That name is deleted and is't descriped in the persistance.xml nor in the sun-resources.xml. There is no such entry in the Services in Netbeans.
Have you seen such an error, and how can I make sure, that netbeans doesn't store information on places I can't reach from the IDE? How is it so that my application is looking for something that isn't listed anywhere...
Okay next time I have to think more, instead of asking the question here. So my problem was the cache directory of Netbeans 6.9.1.
Deleted the cache directory and everything started working again.
I hope that this problem is fixed in the next releases. it can be real pain in ... :)