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?
Related
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
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.
I added a field to this table: STG_INVOICE_SUP_VW
But then I wasn't able to synchronize the table so I deleted it. Now if I'm trying to synchronize any table it's throwing this error below:
Cannot execute a data definition language command on (). The SQL
database has issued an error.
SQL error description: [Microsoft][SQL Server Native Client 11.0][SQL
Server]Cannot drop the index
'STG_INVOICE_SUP_VW._dta_index_STG_INVOICE_SUP_VW_25_692157136__K7_1_2_3_4_5_6_8_9_10_11_12_13_14_15_16_17_1',
because it does not exist or you do not have permission.
SQL statement: DROP INDEX
STG_INVOICE_SUP_VW._dta_index_STG_INVOICE_SUP_VW_25_692157136__K7_1_2_3_4_5_6_8_9_10_11_12_13_14_15_16_17_1
Problems during SQL data dictionary synchronization. The operation
failed.
Synchronize failed on 1 table(s)
Edit:
Entire issue was related to an additional index created from SQL side.
If you create an Index on AX tables from SQL side then either you won't be able to synchronize the table or your created index will be dropped on synchronization(as suggested by by some users).You should create indexes from Application Object Tree.
I Deleted the index from SSMS and then synchronize worked perfectly.
It also solved one more issue. Incremental CIL was throwing an error below:
Cannot create a record in SysXppAssembly (SysXppAssembly). The record
already exists.
For incremental CIL issue I had already done the steps pointed here but it didn't fix it:
Stop the AOS Navigate to the XppIL folder in your AOS server
“C:\Program Files\Microsoft Dynamics
AX\60\Server\YourAXInstanceName\bin\XppIL”
Backup the files from the XppIL folder.
Delete the files from the XppIL folder. Note: files
only not sub folders.
Restart the AOS.
The XppIL folder files will be created after the AOS restart
From this link: Community.Dynamics
After fixing the table sync issue, Incremental CIL ran without issue.
Try creating index STG_INVOICE_SUP_VW._dta_index_STG_INVOICE_SUP_VW_25_692157136__K7_1_2_3_4_5_6_8_9_10_11_12_13_14_15_16_17_1 directly in SQL Server and then re-run DB sync in AX.
I am trying to insert file from table to one of the hdfs directory. It does transfer successfully and create the file. but, i am unable to see the data lineage on the cloudera navigator.
I am posting my command below can anyone help what could be the issue, is with the syntax or we have to configure some setting into the navigator.
Syntax:
insert overwrite directory '/user/demo/test_demo' select age, id from demo1;
Also, on the web portal of known issues they mentioned that it should show.
Link: https://www.cloudera.com/documentation/enterprise/release-notes/topics/cn_rn_known_issues.html#hive_hue
As the above query comes under operation execution. when you copy the above query in navigator search bar and from filters select operation execution you would be able to see the data lineage.
If you search for the result based on the out put directory it won't show anything as it a hive operation execution !
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.