schema_version column version not nullable on Sybase ASE

[chrstnk]

What version of Flyway are you using?

4.0.3

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)

Java API

What database are you using (type & version)?

Sybase ASE 15.0.3

What operating system are you using?

UNIX/LINUX

What did you do?

(Please include the content causing the issue, any relevant configuration settings, and the command you ran)
ran migrate for the first time including repeatable migrations that don't have a version

What did you expect to see?

schema_version contains a record for the repeatable migration with null values for version

What did you see instead?

java.sql.SQLException: Attempt to insert NULL value into column 'version', table '.....dbo.schema_version'; column does not allow nulls. Update fails.

looked at org.flywaydb.core.internal.dbsupport.sybaseASE.createMetaDataTable.sql and found below
CREATE TABLE ${table} (
...,
version VARCHAR(50),
...

Sybase' default is NOT NULL so the column should be defined as nullable.

[ogerardin]

Same with Sybase 12.5

[mturuta]

Same for Sybase 15.7.
I tried adding a statement to make the schema_version.version nullable and run it through flyway but the migration just hangs the statement never completes.
Is the workaround of making the schema_version.version nullable manually acceptable?
Will it cause issues down the road?

[ogerardin]

@mturuta I did it manually outside of flyway and I have observed no issues.

[axelfontaine]

The table must have been created with a pre-release of Flyway 4.0 as ever since the official release this column has always been nullable.

[ogerardin]

No the table was created with the latest 4.0.3
In the Sybase script that creates the table, the column is not declared as NULL or NOT NULL so Sybase defaults to NOT NULL.
I suggest adding "NULL" to the script (whcih I did) so there is no ambiguity.

[axelfontaine]

@ogerardin Thank you very much for clarifying! That was a huge help! I guess I must have overlooked the last line in @chrstnk 's original report (facepalm!)