If some script fails during migration , flyway won't add record to schema_version in DB2 db for failed statement.
Do you have any idea how to avoid this situation?
I did a migration, 4th script failed, i expect this script will have status ABORTED/FAILED
One explanation for flyway behavior difference that you observe is the way Oracle handles DDL (implicit commit before/after each DDL) as compared with how Db2 handles DDL (implements DDL under transaction control by default). So with Db2 it's possible to arrange for each migration to be atomic and to rollback upon failure - meaning that there is nothing to repair, and therefore no repair action required as the flyway Oracle implementation may need.
Related
I want to make a change to the postgres.conf file at runtime. However, when I execute the sql with "alter system" via hibernate I get an error
Transaction is marked for rollback only or has timed out
I think this has something to do with alter system commands not allowed to execute inside a transaction block as per the documentation
Only superusers can use ALTER SYSTEM. Also, since this command acts directly on the file system and cannot be rolled back, it is not allowed inside a transaction block or function.
Im trying to understand if its possible to execute this type of command with hibernate and what I need to do to be able to do that?
Is it possible to recreate the following in redshift sql workbench?
create table test as
select top 10 * from core_data;
savepoint sv;
delete from test
where name like 'A%';
savepoint sv2;
delete from test
where name like 'B%';
rollback to sv;
Redshift doesn't support Rollback to Savepoints at all by any means. Hence you can't do with workbench as well.
See here list of all the unsupported PostgreSQL functions by Redshift. It includes savepoints as well.
If you execute rollback to savepoint query to Redshift like,
rollback to savepointexample;
You will see following error.
ERROR: SQL command "rollback to savepoint sv3;" not supported.
I was trying to run flyway:migrate on my projects postgres database. I have made the changes to a table manually and because of that the schema migration using flyway is failing, which is blocking next schema migration execution.
table : foo
required_change : ALTER TABLE foo ALTER COLUMN id DROP NOT NULL
current_schema_version : 2
next_schema_version : 3
Error:
[ERROR] com.googlecode.flyway.core.api.FlywayException: Migration of schema "public" to version 3 failed! Changes successfully rolled back.
How could I skip failing schema and make flyway:migrate execute next schema defined?
It might be simplest to undo the manual change so that Flyway can run successfully. For example, if you dropped the column then add it back in, then run the Flyway script to drop it.
So I found one possible solution to this problem, which goes as follows:
(1). In mysql database there is a table schema_version, which maintains the migration version number , it's status and other related information.
for ex.
mysql> desc schema_version;
version_rank
installed_rank
version
description
type
script
checksum
installed_by
installed_on
execution_time
success
for a failed migration the success field values stores 0, to override that and execute the next flyway:migration you can manually set the value to 1 (this would make sure, you don't lose the data stored on the table you created manually , when migration failed.
(2). Adding following on your pom.xml while running flyway:migration temporarily (while testing) also helps.
<validateOnMigrate>false</validateOnMigrate>
It looks like when a run a migration which fails, that migration is not added to the schema.version table but is reflected locally as pending state in the info command.
Given this, repair is not required as there is no checksum stored in schema.version.
So I suppose my question is; is there a scenario where repair is required for PostgreSQL and also, what scenario puts a row into schema_version that has a non-TRUE value for success?
You are correct. For PostgreSQL and other databases with DDL transaction support, success is always true.
The only time repair is required, is when for some reason you had to change a migration and the checksums need to be realigned.
The updateSQL liquibase command does not seem to throw an error when running updateSQL command line as it generates the relevant SQL statements for the changeset along with an entry to be created in DATABASECHANGELOG table.
My requirement is that I can only generate the SQL and hand it over to my DBA. But will liquibase throw error even if one of the changeSets in the xml fails to get created prior to generating the SQL for the changeset ?
Please help
UpdateSQL will not fail if a changeSet is already ran. The purpose of Liquibase is to track which changeSets have been applied and only "execute" changeSets that have not been ran while skipping ones that have.
If you run in regular update mode, Liquibase will directly execute each changeSet in turn. If you run in updateSql mode, Liquibase will not actually execute the SQL but instead output what it would have ran.
Liquibase will not throw any errors in updateSQL. However, if the state of the database you are going to execute the SQL file against is different than the database you run updateSQL against, the resulting SQL may not be valid. There is no re-checking of whether a changeSet has executed in the SQL output, it is just a simple "run these commands" script.