Known bug with flyways SQL parser?

When executing Flyway migrate on a generic database object file containing the following table creation:

CREATE TABLE "T_MY_TABLE"

( "ID" NUMBER,

"ID_PERSON" NUMBER,

"PERSONNR" VARCHAR2(12 CHAR),

"VERSION" NUMBER,

"TIMESTAMP" TIMESTAMP (6) DEFAULT SYSTIMESTAMP

) ENABLE ROW MOVEMENT ;

It seems like Flyway does not understand that SYSTIMESTAMP is an actuall data type and assigns it as a string. Example to se difference with SQL query:

SELECT DATA_DEFAULT FROM USER_TAB_COLUMNS WHERE TABLE_NAME = 'T_MY_TABLE';

If however i change postion and put the version column or any other column without the Deafult attribute at the bottom and as a result putting a "," behind the default column it gets corrected. Is this a known bug or am I just doing something weird?

FYI am using Flyway community 9.22.3

Johannes 2 months ago

Comments

2 comments

Flyway won't change your SQL (except for placeholder replacement but you aren't using that) - all it does is to break it up into statements and pass it to the database driver to be applied to the DB.

AlistairW 2 months ago

0
It doesn't change the existing schema, excuse my english.

If we clean the database in between migrations so that we have a completly blank DB, then run migrate with the 2 diffrenet options I presented in the previous post, using the V1__Database_Object to create the schema. The option with a Default attribute at the bottom(without a "," at the end) will assign data_defualt to be a string and not call the method for in this case the SYSTIMESTAMP.

JoHa 2 months ago

0