I have run the Corda DB Migration tool and created a .jar containing .sql scripts of the tables that represent the States Objects of my CordApps as explained in https://docs.corda.r3.com/database-management.html#database-management-tool
However after putting the .jar in the /cordapps folder of my node, I got an error indicating the Checksum Verification is failing: "liquibase.exception.ValidationFailedException: Validation Failed: 2 change sets check sum..."
Do you know how could I reset the checksum of my objects so that the verification does not fail and I could start the Corda Node successfully?
Thank you
Stan
Truncate your migration related table i.e. databasechangelog & databasechangeloglock. I think truncating only databasechangelog should do the trick for you.
This can happen if you change existing migration scripts which have been run previously. Corda will attempt to check the migration scripts against what has been run and find that the scripts no longer match.
For example: "MyApp" version 1.0 has a migration "init" script that creates table FooBar. On starting the node the table is created and the databasechangelog and databasechangeloglock tables insert a record the migration.
Then "MyApp" version 1.1 comes out which has a modified version of the "init" script. This new script matches the name of the script previously run on version 1.0 but no longer matches the checksum as the content has changed.
Kid101's solution does work but you would only need to delete the relevant entry for the changed script in databasechangelog and databasechangeloglock. Also note that new Corda nodes will skip the original migration and start on version 1.1 which will bypass the issue.
Related
Starting working on an existing Java web application project with Flyway, I am unable to deploy it due to an owner-related issue, "sequence must have same owner as table it is linked to". The sql state is "55000" and the error code is 0.
A DB script for Flyway
create sequene if not exists my_db.my_table_uid_seq
start 1
increment by 1000
owned by my_db.my_table.uid
and the table to which the sequence is linked to has
create table if not exists my_db.my_table (...);
alter table my_db.my_table owner to userx;
The problem can be resolved if I can drop the "owned by ...".
With Flyway, the task should be carried out by a script file with a content
drop owned by my_db.my_table.uid
Because those script files are running by sequence, the script file with the above content will run last. That means that the previous script will run and the error won't be resolved.
How to resolve the problem then?
I'm using flyway for migrations. Flyway version is Flyway 3.2.1 by Boxfuse. When I am executing
./flyway migrate -url=jdbc:postgresql://$FLYWAY_DATABASE_HOST/$FLYWAY_DATABASE_NAME -password=$FLYWAY_DATABASE_PASSWORD -user=$FLYWAY_DATABASE_USER
I'm getting following error
"ERROR: Validate failed. Migration Checksum mismatch for migration 80
Applied to database : -401430104
Resolved locally : -485639995
How can I resolve this?
Migration Checksum mismatch means that the contents of a particular migration file has changed since you executed it, and that means that your script collection might not be a faithful representation of the database schema.
If you are happy that the scripts are still good (eg the changes were comments and formatting) then flyway repair with the same URL and credentials will clear this error. If not, then you should either revert the changes, or flyway repair and accept the mismatch.
I have installed Flyway Software and trying to deploy code. I have a Scenario
I created a file V1_01_CREATE_TABLE.SQL to create a table.
Created a file V1_01_CREATE_PACKAGE.SQL - This package will hold code to insert a row into one of the columns in table created in step 1.
Created a file V1_01_02_ALTER_TABLE.SQL - This SQL will rename the column which was being referred in step2.
This will invalidate the package if I run 1, 2 & 3. How does FLYWAY handle such a situation? Does it understand object dependency?
As explained in the manual, Flyway simply passes your SQL scripts to the database to be executed, and records the success or failure of their execution.
Flyway has no interest or understanding of the content of your scripts. Flyway never looks at the content of those scripts. In that sense, there is no “intelligence” in Flyway.
Flyway is like the postal worker delivering your letters without opening the envelope. You are the author, and you take full responsibility for the logic and correctness of the SQL scripts. You are responsible for following the naming conventions so your scripts run in the correct order.
After initially creating its metadata table, Flyway makes very limited use of JDBC and SQL. Flyway does little more than make a connection to the database server, determine which of the scripts have yet to be run, and say to the database “Here, run this script, and this script, and then run this script.” while recording the success or failure of each run.
You should name your scripts in order they needs to be executed
V1.0.0_CREATE_TABLE.SQL
V1.0.1_CREATE_PACKAGE.SQL
V1.0.2_ALTER_TABLE.SQL
This will execute scripts in migrated
So while building a new database using our database migration scripts written in a springboot flyway project, we realized we made some mistakes.
Some old scripts need to be changed to ensure that we do not face these issues when we make a new database schema again. These issues are mostly related - an info table was not populated with entries in the project and there are scripts that refer to the data in the migration project -- this data does not exist because we never included a script to include data.
How can we correct this project - the only way I can think of is to correct scripts such that all inserts are replaced by - insert if not exists or replace create statements by create if not exists.
and then delete all entries in schema version and re-run this on all the database which are using this schema.
I cannot go back and correct my script because then the migration project will fail because of checksum issues.
You are rigth, if this project and the scripts are running in some existing projects you can not modify them because the checksum would fail.
Then the cleanest way I can think would be add a file called "DB-GENERAL-FIXES" or something like that, where you can add all SQL validations to restore the DB to a stable status. For the new implementations will be extra work first build it wrongly and then clean it, but if you are sharing the same code in production right now...is the best option
OUR SYSTEM
We are trying to put migrations as .sql files under version control. Developers would write a VN__*.sql file, commit to version control and a job that runs every 5 minutes would automatically migrate to a Dev and Test database. Once the change proved to not cause problems, someone else would run a manual job to run the migration on Production.
MY PROBLEM:
I had a demo migration that created a few tables. I checked V4__DemoTables.sql into version control on my PC.
On our Linux box a job that runs every 5 minutes extracted the new file from version control, then ran the flyway.sh file. It detected the file and executed it.
But the .sql file had a typo. And we are using Neteeza which has problems with flyway automatically wrapping a migration in a BEGIN TRAN ... END TRAN. So the migration created 2 tables, then aborted before the third.
No problem I thought. I dropped the 2 tables that the .sql file did create. Checked V4__ out of version control, fixed the typo and re-submitted it.
Five minutes later the update was extracted but flyway complains that the checksum does not match. So it will NOT run the updated V4__DemoTables.sql file.
How do I get flyway to accept the updated file and update the checksum in the SCHEMA_VERSION file in case of a typo?
Reading the docs it seems like the developers suggest I should have created a new V4_1_DemoTables.sql file with the fix's. But this would have collided with the commands in the V4__ file so this seemed wrong.
So here is what the docs imply I need to do:
Leave V4__ as a 'successful' migration according to the
SCHEMA_VERSION table.
Create V4_1_ to delete the tables that were created before the typo
line in V4__.
Create V4_2_ which has the typo fix from the original file to do all
the real work.
Is this correct?
If the migration completes successfully, but some of the db objects are not quite right yet (typo in column name, ...), do as you said and push a follow-up script that fixes it (rename column, ...).
If the migration fails, and it didn't run on a DB with DDL transaction, the DB must be cleaned manually. This means:
Reverting the effects of the migration on the DB
Removing the version from the SCHEMA_VERSION table and marking the previous one as current
This second step will be automated in the future with the introduction of the flyway.repair() command.