[
https://issues.apache.org/jira/browse/FINERACT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117381#comment-17117381
]
Petri Tuomola commented on FINERACT-1008:
-----------------------------------------
This Flyway upgrade is really a pain, isn't it!
Reading through the issue: it seems that the problem is that you should not go
directly from Flyway 4 to Flyway 6 as this breaks one of the Flyway tables.
Instead, you should migrate first to Flyway 5.
Three solutions are proposed:
* Manually create the relevant tables with SQL and then run repair. I suppose
we could do this, but running direct SQL from Gradle sort of defeats the whole
point of Flyway
* First migrate to Flyway 5, ensure that all databases are upgraded, and then
only later upgrade to Flyway 6. But can we guarantee that everyone will
download and use the version of Fineract that relies on Flyway 5 before using
the version with Flyway 6? Probably not...
* Manually download Flyway 5 and run it against the database as a standalone
executable. But this requires setting up a separate config, classpath etc for
Flyway 5 in the Gradle file (as well as some magic to work out when you should
run this task)
Personally I would probably take the easy way out and go back to Flyway 5 for
12 months or so... and then upgrade to latest version. Any thoughts?
> Field 'version_rank' doesn't have a default value (blocking updates on
> fineract.dev)
> ------------------------------------------------------------------------------------
>
> Key: FINERACT-1008
> URL: https://issues.apache.org/jira/browse/FINERACT-1008
> Project: Apache Fineract
> Issue Type: Bug
> Affects Versions: 1.4.0
> Reporter: Michael Vorburger
> Priority: Blocker
> Fix For: 1.4.0
>
>
> See FINERACT-932 for general background; I'm currently seeing this in logs of
> https://www.fineract.dev, and it's preventing upgrading the demo to recently
> merged PRs:
> {noformat}Caused by: java.sql.SQLException: Field 'version_rank' doesn't have
> a default value
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException
> (SQLError.java:129)
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException
> (SQLError.java:97)
> at
> com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException
> (SQLExceptionsMapping.java:122)
> at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal
> (ClientPreparedStatement.java:953)
> at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal
> (ClientPreparedStatement.java:1092)
> at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal
> (ClientPreparedStatement.java:1040)
> at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate
> (ClientPreparedStatement.java:1347)
> at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdate
> (ClientPreparedStatement.java:1025)
> at org.flywaydb.core.internal.jdbc.JdbcTemplate.update
> (JdbcTemplate.java:331)
> at
> org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.doAddAppliedMigration
> (JdbcTableSchemaHistory.java:163)
> at
> org.flywaydb.core.internal.schemahistory.SchemaHistory.addAppliedMigration
> (SchemaHistory.java:163)
> at org.flywaydb.core.internal.command.DbMigrate.doMigrateGroup
> (DbMigrate.java:384)
> at org.flywaydb.core.internal.command.DbMigrate.access$200
> (DbMigrate.java:54)
> at org.flywaydb.core.internal.command.DbMigrate$3.call
> (DbMigrate.java:282)
> at
> org.flywaydb.core.internal.jdbc.TransactionalExecutionTemplate.execute
> (TransactionalExecutionTemplate.java:66)
> at org.flywaydb.core.internal.command.DbMigrate.applyMigrations
> (DbMigrate.java:279)
> at org.flywaydb.core.internal.command.DbMigrate.migrateGroup
> (DbMigrate.java:244)
> at org.flywaydb.core.internal.command.DbMigrate.access$100
> (DbMigrate.java:54)
> at org.flywaydb.core.internal.command.DbMigrate$2.call
> (DbMigrate.java:162)
> at org.flywaydb.core.internal.command.DbMigrate$2.call
> (DbMigrate.java:159)
> at
> org.flywaydb.core.internal.database.mysql.MySQLNamedLockTemplate.execute
> (MySQLNamedLockTemplate.java:60)
> at org.flywaydb.core.internal.database.mysql.MySQLConnection.lock
> (MySQLConnection.java:161)
> at
> org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.lock
> (JdbcTableSchemaHistory.java:140)
> at org.flywaydb.core.internal.command.DbMigrate.migrateAll
> (DbMigrate.java:159)
> at org.flywaydb.core.internal.command.DbMigrate.migrate
> (DbMigrate.java:137)
> at org.flywaydb.core.Flyway$1.execute (Flyway.java:199)
> at org.flywaydb.core.Flyway$1.execute (Flyway.java:159)
> at org.flywaydb.core.Flyway.execute (Flyway.java:530)
> at org.flywaydb.core.Flyway.migrate (Flyway.java:159)
> at
> org.apache.fineract.infrastructure.core.service.TenantDatabaseUpgradeService.upgradeAllTenants
> (TenantDatabaseUpgradeService.java:80){noformat}
> The "trigger" seems to have been the merge of [~fynmanoj]'s
> https://github.com/apache/fineract/pull/769 for FINERACT-893 by [~avikg]
> ([~avikganguly] ? [~avikganguly010] ??) but the
> {{core_db/V358__fixed_deposit_rollover_transfer.sql}} from that PR is
> unlikely to have caused this?
> Field {{version_rank}} which _doesn't have a default value_ appears to be in
> (Flyway's own!) {{schema_version}} table, defined in
> https://github.com/apache/fineract/blob/develop/fineract-db/mifospltaform-tenants-first-time-install.sql
> ... so is this an impact of and related to FINERACT-979 / FINERACT-810 ?
> (Perhaps that PR above was just the first time that we merged a PR with a
> schema migration after the Flyway upgrade?)
> I haven't been able to locally reproduce this though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
