Re: Migration to latest

[Michael Vorburger]

Sergio,


On Mon, 15 Jun 2020, 12:22 Sergio Junior,  wrote:

> Guys,
>
> Sorry to ask, but there are plans to keep compatibility between updates?
>

That IS the plan, and why we use Flyway - yeah... ;-)


> I just updated our docker image to the latest version, and again the
> Flyway cannot apply migrations.
>
> The first problem was, "flyway_schema_history" table changed to
> "schema_version", I had to correct it manually.
>

https://issues.apache.org/jira/FINERACT-979 was (supposed to) fixed this
problem.. would you like to contribute to the project by investigating how
come that doesn't work for you?

After that, migrations failed when applying changes regarding the
> table: x_registered_table
>

This seems to be a new problem. You're welcome to a file a JIRA with steps
documenting how to reproduce this. If you can help further analyse it or
even contribute a fix, even better.

M.

So updating the version is still not straightforward, always needs some
> manual fix on the database.
>
> I will let it create databases from scratch and perform a schema compare.
>
> Em sáb., 16 de mai. de 2020 às 17:05, Vishwas Babu A J <
> vishwasbab...@gmail.com> escreveu:
>
>> Hi Guys,
>>
>> >>Only 5.7 and 8.0 still available at the community edition.
>>
>> I am not sure if this is an issue. Ext. support for MySQL 5.6 is
>> scheduled to end on Feb 2021, so we would also likely drop support for
>> MySQL 5.6 in the very near future.
>>
>> >> Aws Aurora Serverless only supports 5.6
>> Ah, I see. I would guess the wouldn’t be too far away.  As a
>> workaround, Aurora MySQL 2.* database engine is compatible with MySQL 5.7
>> and available in most regions.
>>
>> Regards,
>> Vishwas
>>
>>
>>
>> On May 16, 2020, at 12:04 PM, Sergio Junior  wrote:
>>
>> Michael,
>>
>> Its specified here:
>> https://flywaydb.org/documentation/database/mysql
>>
>> Only 5.7 and 8.0 still available at the community edition.
>>
>> Aws Aurora Serverless only supports 5.6
>>
>>
>> On Sat, May 16, 2020, 11:35 Michael Vorburger  wrote:
>>
>>> On Sat, May 16, 2020 at 2:19 AM Sergio Junior 
>>> wrote:
>>>
 Also, i can make a script if you need.

>>>
>>> A SQL script to rename the table would have that problem that Awasum
>>> noticed - it's a "chicken and egg" - we can't easily use Flyway to run a
>>> migration script to fix a problem with Flyway... ;-)
>>>
>>> Just making it the new version of Flyway use its old table name via that
>>> property which Petri discovered (thanks!) seemed the most "pragmatic"
>>> solution, to me.
>>>
>>> I've just done this in https://github.com/apache/fineract/pull/897, and
>>> can confirm it does fix
>>> https://issues.apache.org/jira/browse/FINERACT-979 (I've locally
>>> reproduced the problem, and seen it solved with that PR).
>>>
>>> We had 2 scenarios.
 From Mifos X to fineract (gotta check, we used a docker version from
 March, dont know exactly which one) i had to manually diff schema and data
 using dbForge to make it work.

 Then to fineract develop, need to rename schema_version tables to
 Flyway_schema_history.
 Just the tenants db that i let Fineract create from scratch.

 On Fri, May 15, 2020, 21:14 Sergio Junior  wrote:

> Michael,
>
> Sharing more info with you, i had multiple problems with Flyway.
>
> We were using Aws aurora serverless and it's Mysql 5.6
> With the Drizzle driver, the error was unfriendly. Changing to the
> Mysql driver, Flyway returned that the Community Version doesn't support
> 5.6 anymore, just the enterprise version.
>

>>> Do you want to file a JIRA issue with details including the error
>>> message you encountered re ^^^ this other point?
>>> https://flywaydb.org/download/ does not mention their Community Edition
>>> not supporting MySQL 5.6 anymore. In fact, the project's Docker Compose
>>> set-up uses 5.7, and Flyway seems to work fine.
>>>
>>>
 I upgraded our Db (lost the serverless capability :( and then had to
> rename tables manually.
>
> Imho, Flyway seems a bad option because they can keep removing mysql
> versions from the community edition, forcing people to the enterprise.
>
> Im from the dotnet world, do not have much experience with java libs,
> but we should have a better alternative.
>
> Thanks!
>
>
> On Fri, May 15, 2020, 17:28 Awasum Yannick  wrote:
>
>> This will need a new migration script or file...I dont think Flyway
>> will even run automatically...Was just a thought
>>
>> On Fri, May 15, 2020 at 9:27 PM Awasum Yannick 
>> wrote:
>>
>>> can we just rename schema_version to flyway_schema_history ? How
>>> practical is that? see :
>>> https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/
>>>
>>> So we use updated naming convention by Flyway?
>>>
>>>
>>>
>>> On Fri, May 15, 2020 a

Re: Migration to latest

[Sergio Junior]

Guys,

Sorry to ask, but there are plans to keep compatibility between updates?

I just updated our docker image to the latest version, and again the Flyway
cannot apply migrations.

The first problem was, "flyway_schema_history" table changed to
"schema_version", I had to correct it manually.
After that, migrations failed when applying changes regarding the
table: x_registered_table

So updating the version is still not straightforward, always needs some
manual fix on the database.

I will let it create databases from scratch and perform a schema compare.

Em sáb., 16 de mai. de 2020 às 17:05, Vishwas Babu A J <
vishwasbab...@gmail.com> escreveu:

> Hi Guys,
>
> >>Only 5.7 and 8.0 still available at the community edition.
>
> I am not sure if this is an issue. Ext. support for MySQL 5.6 is scheduled
> to end on Feb 2021, so we would also likely drop support for MySQL 5.6 in
> the very near future.
>
> >> Aws Aurora Serverless only supports 5.6
> Ah, I see. I would guess the wouldn’t be too far away.  As a
> workaround, Aurora MySQL 2.* database engine is compatible with MySQL 5.7
> and available in most regions.
>
> Regards,
> Vishwas
>
>
>
> On May 16, 2020, at 12:04 PM, Sergio Junior  wrote:
>
> Michael,
>
> Its specified here:
> https://flywaydb.org/documentation/database/mysql
>
> Only 5.7 and 8.0 still available at the community edition.
>
> Aws Aurora Serverless only supports 5.6
>
>
> On Sat, May 16, 2020, 11:35 Michael Vorburger  wrote:
>
>> On Sat, May 16, 2020 at 2:19 AM Sergio Junior 
>> wrote:
>>
>>> Also, i can make a script if you need.
>>>
>>
>> A SQL script to rename the table would have that problem that Awasum
>> noticed - it's a "chicken and egg" - we can't easily use Flyway to run a
>> migration script to fix a problem with Flyway... ;-)
>>
>> Just making it the new version of Flyway use its old table name via that
>> property which Petri discovered (thanks!) seemed the most "pragmatic"
>> solution, to me.
>>
>> I've just done this in https://github.com/apache/fineract/pull/897, and
>> can confirm it does fix
>> https://issues.apache.org/jira/browse/FINERACT-979 (I've locally
>> reproduced the problem, and seen it solved with that PR).
>>
>> We had 2 scenarios.
>>> From Mifos X to fineract (gotta check, we used a docker version from
>>> March, dont know exactly which one) i had to manually diff schema and data
>>> using dbForge to make it work.
>>>
>>> Then to fineract develop, need to rename schema_version tables to
>>> Flyway_schema_history.
>>> Just the tenants db that i let Fineract create from scratch.
>>>
>>> On Fri, May 15, 2020, 21:14 Sergio Junior  wrote:
>>>
 Michael,

 Sharing more info with you, i had multiple problems with Flyway.

 We were using Aws aurora serverless and it's Mysql 5.6
 With the Drizzle driver, the error was unfriendly. Changing to the
 Mysql driver, Flyway returned that the Community Version doesn't support
 5.6 anymore, just the enterprise version.

>>>
>> Do you want to file a JIRA issue with details including the error message
>> you encountered re ^^^ this other point? https://flywaydb.org/download/
>> does not mention their Community Edition not supporting MySQL 5.6 anymore.
>> In fact, the project's Docker Compose set-up uses 5.7, and Flyway seems to
>> work fine.
>>
>>
>>> I upgraded our Db (lost the serverless capability :( and then had to
 rename tables manually.

 Imho, Flyway seems a bad option because they can keep removing mysql
 versions from the community edition, forcing people to the enterprise.

 Im from the dotnet world, do not have much experience with java libs,
 but we should have a better alternative.

 Thanks!


 On Fri, May 15, 2020, 17:28 Awasum Yannick  wrote:

> This will need a new migration script or file...I dont think Flyway
> will even run automatically...Was just a thought
>
> On Fri, May 15, 2020 at 9:27 PM Awasum Yannick 
> wrote:
>
>> can we just rename schema_version to flyway_schema_history ? How
>> practical is that? see :
>> https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/
>>
>> So we use updated naming convention by Flyway?
>>
>>
>>
>> On Fri, May 15, 2020 at 9:02 PM Michael Vorburger 
>> wrote:
>>
>>> Petri, that sounds like the kind of thing I was hoping someone
>>> looking into it would find... not sure what "property" they are 
>>> referring
>>> to here - is this something we could put into...
>>> TenantDatabaseUpgradeService is guess where this would go. Fancy 
>>> putting a
>>> PR together, perhaps?
>>>
>>> Sergio, would you be interested in contributing to the project by
>>> helping to such a PR, if you still have or can build an "old" database?
>>>
>>> On Fri, May 15, 2020 at 9:31 PM Petri Tuomola 
>>> wrote:
>>>
 Hi

 Looki

Re: Migration to latest

[Vishwas Babu A J]

Hi Guys,

>>Only 5.7 and 8.0 still available at the community edition.

I am not sure if this is an issue. Ext. support for MySQL 5.6 is scheduled to 
end on Feb 2021, so we would also likely drop support for MySQL 5.6 in the very 
near future. 

>> Aws Aurora Serverless only supports 5.6
Ah, I see. I would guess the wouldn’t be too far away.  As a workaround, Aurora 
MySQL 2.* database engine is compatible with MySQL 5.7 and available in most 
regions.

Regards,
Vishwas



> On May 16, 2020, at 12:04 PM, Sergio Junior  wrote:
> 
> Michael,
> 
> Its specified here:
> https://flywaydb.org/documentation/database/mysql 
> 
> 
> Only 5.7 and 8.0 still available at the community edition.
> 
> Aws Aurora Serverless only supports 5.6
> 
> 
> On Sat, May 16, 2020, 11:35 Michael Vorburger  > wrote:
> On Sat, May 16, 2020 at 2:19 AM Sergio Junior  > wrote:
> Also, i can make a script if you need.
> 
> A SQL script to rename the table would have that problem that Awasum noticed 
> - it's a "chicken and egg" - we can't easily use Flyway to run a migration 
> script to fix a problem with Flyway... ;-) 
> 
> Just making it the new version of Flyway use its old table name via that 
> property which Petri discovered (thanks!) seemed the most "pragmatic" 
> solution, to me. 
> 
> I've just done this in https://github.com/apache/fineract/pull/897 
> , and can confirm it does fix 
> https://issues.apache.org/jira/browse/FINERACT-979 
>  (I've locally reproduced 
> the problem, and seen it solved with that PR).
> 
> We had 2 scenarios. 
> From Mifos X to fineract (gotta check, we used a docker version from March, 
> dont know exactly which one) i had to manually diff schema and data using 
> dbForge to make it work.
> 
> Then to fineract develop, need to rename schema_version tables to 
> Flyway_schema_history.
> Just the tenants db that i let Fineract create from scratch. 
> 
> On Fri, May 15, 2020, 21:14 Sergio Junior  > wrote:
> Michael,
> 
> Sharing more info with you, i had multiple problems with Flyway. 
> 
> We were using Aws aurora serverless and it's Mysql 5.6
> With the Drizzle driver, the error was unfriendly. Changing to the Mysql 
> driver, Flyway returned that the Community Version doesn't support 5.6 
> anymore, just the enterprise version.
> 
> Do you want to file a JIRA issue with details including the error message you 
> encountered re ^^^ this other point? https://flywaydb.org/download/ 
>  does not mention their Community Edition not 
> supporting MySQL 5.6 anymore. In fact, the project's Docker Compose set-up 
> uses 5.7, and Flyway seems to work fine.
>  
> I upgraded our Db (lost the serverless capability :( and then had to rename 
> tables manually. 
> 
> Imho, Flyway seems a bad option because they can keep removing mysql versions 
> from the community edition, forcing people to the enterprise. 
> 
> Im from the dotnet world, do not have much experience with java libs, but we 
> should have a better alternative. 
> 
> Thanks! 
> 
> 
> On Fri, May 15, 2020, 17:28 Awasum Yannick  > wrote:
> This will need a new migration script or file...I dont think Flyway will even 
> run automatically...Was just a thought
> 
> On Fri, May 15, 2020 at 9:27 PM Awasum Yannick  > wrote:
> can we just rename schema_version to flyway_schema_history ? How practical is 
> that? see : 
> https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/
>  
> 
> 
> So we use updated naming convention by Flyway?
> 
> 
> 
> On Fri, May 15, 2020 at 9:02 PM Michael Vorburger  > wrote:
> Petri, that sounds like the kind of thing I was hoping someone looking into 
> it would find... not sure what "property" they are referring to here - is 
> this something we could put into... TenantDatabaseUpgradeService is guess 
> where this would go. Fancy putting a PR together, perhaps?
> 
> Sergio, would you be interested in contributing to the project by helping to 
> such a PR, if you still have or can build an "old" database?
> 
> On Fri, May 15, 2020 at 9:31 PM Petri Tuomola  > wrote:
> Hi
> 
> Looking at the Flyway documentation, I think a possible solution to this 
> would be to set the property flyway.table to point to “schema_version". 
> 
> That way existing installations would not be broken by the Flyway upgrade, as 
> Flyway would continue to use the same table name.
> 
> At least that’s the suggestion from the commit where this change was made to 
> Flyway:
> 
> " You are seeing this message because Flyway changed 
> 

Re: Migration to latest

[Sergio Junior]

Michael,

Its specified here:
https://flywaydb.org/documentation/database/mysql

Only 5.7 and 8.0 still available at the community edition.

Aws Aurora Serverless only supports 5.6


On Sat, May 16, 2020, 11:35 Michael Vorburger  wrote:

> On Sat, May 16, 2020 at 2:19 AM Sergio Junior  wrote:
>
>> Also, i can make a script if you need.
>>
>
> A SQL script to rename the table would have that problem that Awasum
> noticed - it's a "chicken and egg" - we can't easily use Flyway to run a
> migration script to fix a problem with Flyway... ;-)
>
> Just making it the new version of Flyway use its old table name via that
> property which Petri discovered (thanks!) seemed the most "pragmatic"
> solution, to me.
>
> I've just done this in https://github.com/apache/fineract/pull/897, and
> can confirm it does fix https://issues.apache.org/jira/browse/FINERACT-979
> (I've locally reproduced the problem, and seen it solved with that PR).
>
> We had 2 scenarios.
>> From Mifos X to fineract (gotta check, we used a docker version from
>> March, dont know exactly which one) i had to manually diff schema and data
>> using dbForge to make it work.
>>
>> Then to fineract develop, need to rename schema_version tables to
>> Flyway_schema_history.
>> Just the tenants db that i let Fineract create from scratch.
>>
>> On Fri, May 15, 2020, 21:14 Sergio Junior  wrote:
>>
>>> Michael,
>>>
>>> Sharing more info with you, i had multiple problems with Flyway.
>>>
>>> We were using Aws aurora serverless and it's Mysql 5.6
>>> With the Drizzle driver, the error was unfriendly. Changing to the Mysql
>>> driver, Flyway returned that the Community Version doesn't support 5.6
>>> anymore, just the enterprise version.
>>>
>>
> Do you want to file a JIRA issue with details including the error message
> you encountered re ^^^ this other point? https://flywaydb.org/download/
> does not mention their Community Edition not supporting MySQL 5.6 anymore.
> In fact, the project's Docker Compose set-up uses 5.7, and Flyway seems to
> work fine.
>
>
>> I upgraded our Db (lost the serverless capability :( and then had to
>>> rename tables manually.
>>>
>>> Imho, Flyway seems a bad option because they can keep removing mysql
>>> versions from the community edition, forcing people to the enterprise.
>>>
>>> Im from the dotnet world, do not have much experience with java libs,
>>> but we should have a better alternative.
>>>
>>> Thanks!
>>>
>>>
>>> On Fri, May 15, 2020, 17:28 Awasum Yannick  wrote:
>>>
 This will need a new migration script or file...I dont think Flyway
 will even run automatically...Was just a thought

 On Fri, May 15, 2020 at 9:27 PM Awasum Yannick 
 wrote:

> can we just rename schema_version to flyway_schema_history ? How
> practical is that? see :
> https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/
>
> So we use updated naming convention by Flyway?
>
>
>
> On Fri, May 15, 2020 at 9:02 PM Michael Vorburger 
> wrote:
>
>> Petri, that sounds like the kind of thing I was hoping someone
>> looking into it would find... not sure what "property" they are referring
>> to here - is this something we could put into...
>> TenantDatabaseUpgradeService is guess where this would go. Fancy putting 
>> a
>> PR together, perhaps?
>>
>> Sergio, would you be interested in contributing to the project by
>> helping to such a PR, if you still have or can build an "old" database?
>>
>> On Fri, May 15, 2020 at 9:31 PM Petri Tuomola 
>> wrote:
>>
>>> Hi
>>>
>>> Looking at the Flyway documentation, I think a possible solution to
>>> this would be to set the property flyway.table to point to
>>> “schema_version".
>>>
>>> That way existing installations would not be broken by the Flyway
>>> upgrade, as Flyway would continue to use the same table name.
>>>
>>> At least that’s the suggestion from the commit where this change was
>>> made to Flyway:
>>>
>>> " You are seeing this message because Flyway
>>> changed its default for flyway.table in" +
>>> " version 5.0.0 to flyway_schema_history and
>>> you are still relying on the old default (schema_version)." +
>>> " Set flyway.table=schema_version in your
>>> configuration to fix this." +
>>>
>>> Just an idea…
>>>
>>> Regards
>>> Petri
>>>
>>> On 15 May 2020, at 10:15 PM, Michael Vorburger 
>>> wrote:
>>>
>>> Sergio,
>>>
>>> Thank you for having shared this with the developer list. Feedback
>>> like this is a great way to contribute to the project.
>>>
>>> This sounds like it could be due to our recent upgrade of the Flyway
>>> library itself, see https://jira.apache.org/jira/browse/FINERACT-810.
>>> I do find it kind of funny that a tool ma

Re: Migration to latest

[Michael Vorburger]

On Sat, May 16, 2020 at 2:19 AM Sergio Junior  wrote:

> Also, i can make a script if you need.
>

A SQL script to rename the table would have that problem that Awasum
noticed - it's a "chicken and egg" - we can't easily use Flyway to run a
migration script to fix a problem with Flyway... ;-)

Just making it the new version of Flyway use its old table name via that
property which Petri discovered (thanks!) seemed the most "pragmatic"
solution, to me.

I've just done this in https://github.com/apache/fineract/pull/897, and can
confirm it does fix https://issues.apache.org/jira/browse/FINERACT-979
(I've locally reproduced the problem, and seen it solved with that PR).

We had 2 scenarios.
> From Mifos X to fineract (gotta check, we used a docker version from
> March, dont know exactly which one) i had to manually diff schema and data
> using dbForge to make it work.
>
> Then to fineract develop, need to rename schema_version tables to
> Flyway_schema_history.
> Just the tenants db that i let Fineract create from scratch.
>
> On Fri, May 15, 2020, 21:14 Sergio Junior  wrote:
>
>> Michael,
>>
>> Sharing more info with you, i had multiple problems with Flyway.
>>
>> We were using Aws aurora serverless and it's Mysql 5.6
>> With the Drizzle driver, the error was unfriendly. Changing to the Mysql
>> driver, Flyway returned that the Community Version doesn't support 5.6
>> anymore, just the enterprise version.
>>
>
Do you want to file a JIRA issue with details including the error message
you encountered re ^^^ this other point? https://flywaydb.org/download/
does not mention their Community Edition not supporting MySQL 5.6 anymore.
In fact, the project's Docker Compose set-up uses 5.7, and Flyway seems to
work fine.


> I upgraded our Db (lost the serverless capability :( and then had to
>> rename tables manually.
>>
>> Imho, Flyway seems a bad option because they can keep removing mysql
>> versions from the community edition, forcing people to the enterprise.
>>
>> Im from the dotnet world, do not have much experience with java libs, but
>> we should have a better alternative.
>>
>> Thanks!
>>
>>
>> On Fri, May 15, 2020, 17:28 Awasum Yannick  wrote:
>>
>>> This will need a new migration script or file...I dont think Flyway will
>>> even run automatically...Was just a thought
>>>
>>> On Fri, May 15, 2020 at 9:27 PM Awasum Yannick 
>>> wrote:
>>>
 can we just rename schema_version to flyway_schema_history ? How
 practical is that? see :
 https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/

 So we use updated naming convention by Flyway?



 On Fri, May 15, 2020 at 9:02 PM Michael Vorburger 
 wrote:

> Petri, that sounds like the kind of thing I was hoping someone looking
> into it would find... not sure what "property" they are referring to here 
> -
> is this something we could put into... TenantDatabaseUpgradeService is
> guess where this would go. Fancy putting a PR together, perhaps?
>
> Sergio, would you be interested in contributing to the project by
> helping to such a PR, if you still have or can build an "old" database?
>
> On Fri, May 15, 2020 at 9:31 PM Petri Tuomola 
> wrote:
>
>> Hi
>>
>> Looking at the Flyway documentation, I think a possible solution to
>> this would be to set the property flyway.table to point to
>> “schema_version".
>>
>> That way existing installations would not be broken by the Flyway
>> upgrade, as Flyway would continue to use the same table name.
>>
>> At least that’s the suggestion from the commit where this change was
>> made to Flyway:
>>
>> " You are seeing this message because Flyway
>> changed its default for flyway.table in" +
>> " version 5.0.0 to flyway_schema_history and
>> you are still relying on the old default (schema_version)." +
>> " Set flyway.table=schema_version in your
>> configuration to fix this." +
>>
>> Just an idea…
>>
>> Regards
>> Petri
>>
>> On 15 May 2020, at 10:15 PM, Michael Vorburger 
>> wrote:
>>
>> Sergio,
>>
>> Thank you for having shared this with the developer list. Feedback
>> like this is a great way to contribute to the project.
>>
>> This sounds like it could be due to our recent upgrade of the Flyway
>> library itself, see https://jira.apache.org/jira/browse/FINERACT-810.
>> I do find it kind of funny that a tool made to facilitate seamless 
>> database
>> upgrades makes a breaking non-compatible schema change itself... ;-)
>>
>> I guess it would be much nicer if we could fix this to remain
>> compatible. Noticing how https://flywaydb.org/getstarted/how says
>> (quote) "a database with a single empty table called
>> *flyway_schema_history* **by default**" to me mak

Re: Migration to latest

[Sergio Junior]

Also, i can make a script if you need.

We had 2 scenarios.
>From Mifos X to fineract (gotta check, we used a docker version from March,
dont know exactly which one) i had to manually diff schema and data using
dbForge to make it work.

Then to fineract develop, need to rename schema_version tables to
Flyway_schema_history.
Just the tenants db that i let Fineract create from scratch.

On Fri, May 15, 2020, 21:14 Sergio Junior  wrote:

> Michael,
>
> Sharing more info with you, i had multiple problems with Flyway.
>
> We were using Aws aurora serverless and it's Mysql 5.6
> With the Drizzle driver, the error was unfriendly. Changing to the Mysql
> driver, Flyway returned that the Community Version doesn't support 5.6
> anymore, just the enterprise version.
> I upgraded our Db (lost the serverless capability :( and then had to
> rename tables manually.
>
> Imho, Flyway seems a bad option because they can keep removing mysql
> versions from the community edition, forcing people to the enterprise.
>
> Im from the dotnet world, do not have much experience with java libs, but
> we should have a better alternative.
>
> Thanks!
>
>
> On Fri, May 15, 2020, 17:28 Awasum Yannick  wrote:
>
>> This will need a new migration script or file...I dont think Flyway will
>> even run automatically...Was just a thought
>>
>> On Fri, May 15, 2020 at 9:27 PM Awasum Yannick  wrote:
>>
>>> can we just rename schema_version to flyway_schema_history ? How
>>> practical is that? see :
>>> https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/
>>>
>>> So we use updated naming convention by Flyway?
>>>
>>>
>>>
>>> On Fri, May 15, 2020 at 9:02 PM Michael Vorburger 
>>> wrote:
>>>
 Petri, that sounds like the kind of thing I was hoping someone looking
 into it would find... not sure what "property" they are referring to here -
 is this something we could put into... TenantDatabaseUpgradeService is
 guess where this would go. Fancy putting a PR together, perhaps?

 Sergio, would you be interested in contributing to the project by
 helping to such a PR, if you still have or can build an "old" database?

 On Fri, May 15, 2020 at 9:31 PM Petri Tuomola 
 wrote:

> Hi
>
> Looking at the Flyway documentation, I think a possible solution to
> this would be to set the property flyway.table to point to
> “schema_version".
>
> That way existing installations would not be broken by the Flyway
> upgrade, as Flyway would continue to use the same table name.
>
> At least that’s the suggestion from the commit where this change was
> made to Flyway:
>
> " You are seeing this message because Flyway
> changed its default for flyway.table in" +
> " version 5.0.0 to flyway_schema_history and
> you are still relying on the old default (schema_version)." +
> " Set flyway.table=schema_version in your
> configuration to fix this." +
>
> Just an idea…
>
> Regards
> Petri
>
> On 15 May 2020, at 10:15 PM, Michael Vorburger 
> wrote:
>
> Sergio,
>
> Thank you for having shared this with the developer list. Feedback
> like this is a great way to contribute to the project.
>
> This sounds like it could be due to our recent upgrade of the Flyway
> library itself, see https://jira.apache.org/jira/browse/FINERACT-810.
> I do find it kind of funny that a tool made to facilitate seamless 
> database
> upgrades makes a breaking non-compatible schema change itself... ;-)
>
> I guess it would be much nicer if we could fix this to remain
> compatible. Noticing how https://flywaydb.org/getstarted/how says
> (quote) "a database with a single empty table called
> *flyway_schema_history* **by default**" to me makes it sound like it
> may be possible to override and change this so that it's like before...
> would someone like to look more into trying that, testing this, and
> contributing a Pull Request with a solution? I've opened new
> https://jira.apache.org/jira/browse/FINERACT-979 to track this.
>
> Best,
> M.
> ___
> Michael Vorburger
> http://www.vorburger.ch
>
>
> On Fri, May 15, 2020 at 11:02 AM Awasum Yannick 
> wrote:
>
>> Yes, alot of updates have been made over the past few months.
>>
>> Flyway was upgraded along with support for java 11. The DB names were
>> also changed few weeks ago.
>>
>> Check the readme for others having problems with latest Fineract 1.x
>> on the develop branch.
>>
>>
>>
>> On Fri, May 15, 2020, 04:56 Sergio Junior 
>> wrote:
>>
>>> Renaming the schema_version table to flyway_schema_history seems to
>>> have worked.
>>>
>>> Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior <
>

Re: Migration to latest

[Sergio Junior]

Michael,

Sharing more info with you, i had multiple problems with Flyway.

We were using Aws aurora serverless and it's Mysql 5.6
With the Drizzle driver, the error was unfriendly. Changing to the Mysql
driver, Flyway returned that the Community Version doesn't support 5.6
anymore, just the enterprise version.
I upgraded our Db (lost the serverless capability :( and then had to rename
tables manually.

Imho, Flyway seems a bad option because they can keep removing mysql
versions from the community edition, forcing people to the enterprise.

Im from the dotnet world, do not have much experience with java libs, but
we should have a better alternative.

Thanks!


On Fri, May 15, 2020, 17:28 Awasum Yannick  wrote:

> This will need a new migration script or file...I dont think Flyway will
> even run automatically...Was just a thought
>
> On Fri, May 15, 2020 at 9:27 PM Awasum Yannick  wrote:
>
>> can we just rename schema_version to flyway_schema_history ? How
>> practical is that? see :
>> https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/
>>
>> So we use updated naming convention by Flyway?
>>
>>
>>
>> On Fri, May 15, 2020 at 9:02 PM Michael Vorburger 
>> wrote:
>>
>>> Petri, that sounds like the kind of thing I was hoping someone looking
>>> into it would find... not sure what "property" they are referring to here -
>>> is this something we could put into... TenantDatabaseUpgradeService is
>>> guess where this would go. Fancy putting a PR together, perhaps?
>>>
>>> Sergio, would you be interested in contributing to the project by
>>> helping to such a PR, if you still have or can build an "old" database?
>>>
>>> On Fri, May 15, 2020 at 9:31 PM Petri Tuomola  wrote:
>>>
 Hi

 Looking at the Flyway documentation, I think a possible solution to
 this would be to set the property flyway.table to point to
 “schema_version".

 That way existing installations would not be broken by the Flyway
 upgrade, as Flyway would continue to use the same table name.

 At least that’s the suggestion from the commit where this change was
 made to Flyway:

 " You are seeing this message because Flyway
 changed its default for flyway.table in" +
 " version 5.0.0 to flyway_schema_history and
 you are still relying on the old default (schema_version)." +
 " Set flyway.table=schema_version in your
 configuration to fix this." +

 Just an idea…

 Regards
 Petri

 On 15 May 2020, at 10:15 PM, Michael Vorburger 
 wrote:

 Sergio,

 Thank you for having shared this with the developer list. Feedback like
 this is a great way to contribute to the project.

 This sounds like it could be due to our recent upgrade of the Flyway
 library itself, see https://jira.apache.org/jira/browse/FINERACT-810.
 I do find it kind of funny that a tool made to facilitate seamless database
 upgrades makes a breaking non-compatible schema change itself... ;-)

 I guess it would be much nicer if we could fix this to remain
 compatible. Noticing how https://flywaydb.org/getstarted/how says
 (quote) "a database with a single empty table called
 *flyway_schema_history* **by default**" to me makes it sound like it
 may be possible to override and change this so that it's like before...
 would someone like to look more into trying that, testing this, and
 contributing a Pull Request with a solution? I've opened new
 https://jira.apache.org/jira/browse/FINERACT-979 to track this.

 Best,
 M.
 ___
 Michael Vorburger
 http://www.vorburger.ch


 On Fri, May 15, 2020 at 11:02 AM Awasum Yannick 
 wrote:

> Yes, alot of updates have been made over the past few months.
>
> Flyway was upgraded along with support for java 11. The DB names were
> also changed few weeks ago.
>
> Check the readme for others having problems with latest Fineract 1.x
> on the develop branch.
>
>
>
> On Fri, May 15, 2020, 04:56 Sergio Junior  wrote:
>
>> Renaming the schema_version table to flyway_schema_history seems to
>> have worked.
>>
>> Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior <
>> readyh...@gmail.com> escreveu:
>>
>>> Dears,
>>>
>>> We were using the docker version from March dont know exactly which
>>> one it was because theres no tags, just the "latest".
>>> Now we updated the image from docker but the database is not
>>> compatible, the Flyway cannot apply migrations because theres no schema
>>> history table.
>>>
>>> Theres any way to apply the migrations?
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> Atenciosamente,
>> Sergio Luiz Miziara Junior
>> Tel.: (011) 8727.6447
>>
>

Re: Migration to latest

[Awasum Yannick]

This will need a new migration script or file...I dont think Flyway will
even run automatically...Was just a thought

On Fri, May 15, 2020 at 9:27 PM Awasum Yannick  wrote:

> can we just rename schema_version to flyway_schema_history ? How practical
> is that? see :
> https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/
>
> So we use updated naming convention by Flyway?
>
>
>
> On Fri, May 15, 2020 at 9:02 PM Michael Vorburger 
> wrote:
>
>> Petri, that sounds like the kind of thing I was hoping someone looking
>> into it would find... not sure what "property" they are referring to here -
>> is this something we could put into... TenantDatabaseUpgradeService is
>> guess where this would go. Fancy putting a PR together, perhaps?
>>
>> Sergio, would you be interested in contributing to the project by helping
>> to such a PR, if you still have or can build an "old" database?
>>
>> On Fri, May 15, 2020 at 9:31 PM Petri Tuomola  wrote:
>>
>>> Hi
>>>
>>> Looking at the Flyway documentation, I think a possible solution to this
>>> would be to set the property flyway.table to point to “schema_version".
>>>
>>> That way existing installations would not be broken by the Flyway
>>> upgrade, as Flyway would continue to use the same table name.
>>>
>>> At least that’s the suggestion from the commit where this change was
>>> made to Flyway:
>>>
>>> " You are seeing this message because Flyway
>>> changed its default for flyway.table in" +
>>> " version 5.0.0 to flyway_schema_history and you
>>> are still relying on the old default (schema_version)." +
>>> " Set flyway.table=schema_version in your
>>> configuration to fix this." +
>>>
>>> Just an idea…
>>>
>>> Regards
>>> Petri
>>>
>>> On 15 May 2020, at 10:15 PM, Michael Vorburger 
>>> wrote:
>>>
>>> Sergio,
>>>
>>> Thank you for having shared this with the developer list. Feedback like
>>> this is a great way to contribute to the project.
>>>
>>> This sounds like it could be due to our recent upgrade of the Flyway
>>> library itself, see https://jira.apache.org/jira/browse/FINERACT-810. I
>>> do find it kind of funny that a tool made to facilitate seamless database
>>> upgrades makes a breaking non-compatible schema change itself... ;-)
>>>
>>> I guess it would be much nicer if we could fix this to remain
>>> compatible. Noticing how https://flywaydb.org/getstarted/how says
>>> (quote) "a database with a single empty table called
>>> *flyway_schema_history* **by default**" to me makes it sound like it
>>> may be possible to override and change this so that it's like before...
>>> would someone like to look more into trying that, testing this, and
>>> contributing a Pull Request with a solution? I've opened new
>>> https://jira.apache.org/jira/browse/FINERACT-979 to track this.
>>>
>>> Best,
>>> M.
>>> ___
>>> Michael Vorburger
>>> http://www.vorburger.ch
>>>
>>>
>>> On Fri, May 15, 2020 at 11:02 AM Awasum Yannick 
>>> wrote:
>>>
 Yes, alot of updates have been made over the past few months.

 Flyway was upgraded along with support for java 11. The DB names were
 also changed few weeks ago.

 Check the readme for others having problems with latest Fineract 1.x on
 the develop branch.



 On Fri, May 15, 2020, 04:56 Sergio Junior  wrote:

> Renaming the schema_version table to flyway_schema_history seems to
> have worked.
>
> Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior <
> readyh...@gmail.com> escreveu:
>
>> Dears,
>>
>> We were using the docker version from March dont know exactly which
>> one it was because theres no tags, just the "latest".
>> Now we updated the image from docker but the database is not
>> compatible, the Flyway cannot apply migrations because theres no schema
>> history table.
>>
>> Theres any way to apply the migrations?
>>
>> Thanks!
>>
>
>
> --
> Atenciosamente,
> Sergio Luiz Miziara Junior
> Tel.: (011) 8727.6447
>

>>>

Re: Migration to latest

[Awasum Yannick]

can we just rename schema_version to flyway_schema_history ? How practical
is that? see :
https://blog.marceloaltmann.com/en-how-to-rename-table-in-mysql-pt-como-renomear-tabelas-no-mysql/

So we use updated naming convention by Flyway?



On Fri, May 15, 2020 at 9:02 PM Michael Vorburger  wrote:

> Petri, that sounds like the kind of thing I was hoping someone looking
> into it would find... not sure what "property" they are referring to here -
> is this something we could put into... TenantDatabaseUpgradeService is
> guess where this would go. Fancy putting a PR together, perhaps?
>
> Sergio, would you be interested in contributing to the project by helping
> to such a PR, if you still have or can build an "old" database?
>
> On Fri, May 15, 2020 at 9:31 PM Petri Tuomola  wrote:
>
>> Hi
>>
>> Looking at the Flyway documentation, I think a possible solution to this
>> would be to set the property flyway.table to point to “schema_version".
>>
>> That way existing installations would not be broken by the Flyway
>> upgrade, as Flyway would continue to use the same table name.
>>
>> At least that’s the suggestion from the commit where this change was made
>> to Flyway:
>>
>> " You are seeing this message because Flyway
>> changed its default for flyway.table in" +
>> " version 5.0.0 to flyway_schema_history and you
>> are still relying on the old default (schema_version)." +
>> " Set flyway.table=schema_version in your
>> configuration to fix this." +
>>
>> Just an idea…
>>
>> Regards
>> Petri
>>
>> On 15 May 2020, at 10:15 PM, Michael Vorburger  wrote:
>>
>> Sergio,
>>
>> Thank you for having shared this with the developer list. Feedback like
>> this is a great way to contribute to the project.
>>
>> This sounds like it could be due to our recent upgrade of the Flyway
>> library itself, see https://jira.apache.org/jira/browse/FINERACT-810. I
>> do find it kind of funny that a tool made to facilitate seamless database
>> upgrades makes a breaking non-compatible schema change itself... ;-)
>>
>> I guess it would be much nicer if we could fix this to remain compatible.
>> Noticing how https://flywaydb.org/getstarted/how says (quote) "a
>> database with a single empty table called *flyway_schema_history* **by
>> default**" to me makes it sound like it may be possible to override and
>> change this so that it's like before... would someone like to look more
>> into trying that, testing this, and contributing a Pull Request with a
>> solution? I've opened new
>> https://jira.apache.org/jira/browse/FINERACT-979 to track this.
>>
>> Best,
>> M.
>> ___
>> Michael Vorburger
>> http://www.vorburger.ch
>>
>>
>> On Fri, May 15, 2020 at 11:02 AM Awasum Yannick 
>> wrote:
>>
>>> Yes, alot of updates have been made over the past few months.
>>>
>>> Flyway was upgraded along with support for java 11. The DB names were
>>> also changed few weeks ago.
>>>
>>> Check the readme for others having problems with latest Fineract 1.x on
>>> the develop branch.
>>>
>>>
>>>
>>> On Fri, May 15, 2020, 04:56 Sergio Junior  wrote:
>>>
 Renaming the schema_version table to flyway_schema_history seems to
 have worked.

 Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior <
 readyh...@gmail.com> escreveu:

> Dears,
>
> We were using the docker version from March dont know exactly which
> one it was because theres no tags, just the "latest".
> Now we updated the image from docker but the database is not
> compatible, the Flyway cannot apply migrations because theres no schema
> history table.
>
> Theres any way to apply the migrations?
>
> Thanks!
>


 --
 Atenciosamente,
 Sergio Luiz Miziara Junior
 Tel.: (011) 8727.6447

>>>
>>

Re: Migration to latest

[Michael Vorburger]

Petri, that sounds like the kind of thing I was hoping someone looking into
it would find... not sure what "property" they are referring to here - is
this something we could put into... TenantDatabaseUpgradeService is guess
where this would go. Fancy putting a PR together, perhaps?

Sergio, would you be interested in contributing to the project by helping
to such a PR, if you still have or can build an "old" database?

On Fri, May 15, 2020 at 9:31 PM Petri Tuomola  wrote:

> Hi
>
> Looking at the Flyway documentation, I think a possible solution to this
> would be to set the property flyway.table to point to “schema_version".
>
> That way existing installations would not be broken by the Flyway upgrade,
> as Flyway would continue to use the same table name.
>
> At least that’s the suggestion from the commit where this change was made
> to Flyway:
>
> " You are seeing this message because Flyway
> changed its default for flyway.table in" +
> " version 5.0.0 to flyway_schema_history and you
> are still relying on the old default (schema_version)." +
> " Set flyway.table=schema_version in your
> configuration to fix this." +
>
> Just an idea…
>
> Regards
> Petri
>
> On 15 May 2020, at 10:15 PM, Michael Vorburger  wrote:
>
> Sergio,
>
> Thank you for having shared this with the developer list. Feedback like
> this is a great way to contribute to the project.
>
> This sounds like it could be due to our recent upgrade of the Flyway
> library itself, see https://jira.apache.org/jira/browse/FINERACT-810. I
> do find it kind of funny that a tool made to facilitate seamless database
> upgrades makes a breaking non-compatible schema change itself... ;-)
>
> I guess it would be much nicer if we could fix this to remain compatible.
> Noticing how https://flywaydb.org/getstarted/how says (quote) "a database
> with a single empty table called *flyway_schema_history* **by default**"
> to me makes it sound like it may be possible to override and change this so
> that it's like before... would someone like to look more into trying that,
> testing this, and contributing a Pull Request with a solution? I've opened
> new https://jira.apache.org/jira/browse/FINERACT-979 to track this.
>
> Best,
> M.
> ___
> Michael Vorburger
> http://www.vorburger.ch
>
>
> On Fri, May 15, 2020 at 11:02 AM Awasum Yannick  wrote:
>
>> Yes, alot of updates have been made over the past few months.
>>
>> Flyway was upgraded along with support for java 11. The DB names were
>> also changed few weeks ago.
>>
>> Check the readme for others having problems with latest Fineract 1.x on
>> the develop branch.
>>
>>
>>
>> On Fri, May 15, 2020, 04:56 Sergio Junior  wrote:
>>
>>> Renaming the schema_version table to flyway_schema_history seems to have
>>> worked.
>>>
>>> Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior 
>>> escreveu:
>>>
 Dears,

 We were using the docker version from March dont know exactly which one
 it was because theres no tags, just the "latest".
 Now we updated the image from docker but the database is not
 compatible, the Flyway cannot apply migrations because theres no schema
 history table.

 Theres any way to apply the migrations?

 Thanks!

>>>
>>>
>>> --
>>> Atenciosamente,
>>> Sergio Luiz Miziara Junior
>>> Tel.: (011) 8727.6447
>>>
>>
>

Re: Migration to latest

[Petri Tuomola]

Hi

Looking at the Flyway documentation, I think a possible solution to this would 
be to set the property flyway.table to point to “schema_version". 

That way existing installations would not be broken by the Flyway upgrade, as 
Flyway would continue to use the same table name.

At least that’s the suggestion from the commit where this change was made to 
Flyway:

" You are seeing this message because Flyway changed 
its default for flyway.table in" +
" version 5.0.0 to flyway_schema_history and you are 
still relying on the old default (schema_version)." +
" Set flyway.table=schema_version in your configuration 
to fix this." +

Just an idea…

Regards
Petri

> On 15 May 2020, at 10:15 PM, Michael Vorburger  wrote:
> 
> Sergio,
> 
> Thank you for having shared this with the developer list. Feedback like this 
> is a great way to contribute to the project.
> 
> This sounds like it could be due to our recent upgrade of the Flyway library 
> itself, see https://jira.apache.org/jira/browse/FINERACT-810 
> . I do find it kind of 
> funny that a tool made to facilitate seamless database upgrades makes a 
> breaking non-compatible schema change itself... ;-)
> 
> I guess it would be much nicer if we could fix this to remain compatible. 
> Noticing how https://flywaydb.org/getstarted/how 
>  says (quote) "a database with a single 
> empty table called flyway_schema_history **by default**" to me makes it sound 
> like it may be possible to override and change this so that it's like 
> before... would someone like to look more into trying that, testing this, and 
> contributing a Pull Request with a solution? I've opened new 
> https://jira.apache.org/jira/browse/FINERACT-979 
>  to track this.
> 
> Best,
> M.
> ___
> Michael Vorburger
> http://www.vorburger.ch 
> 
> On Fri, May 15, 2020 at 11:02 AM Awasum Yannick  > wrote:
> Yes, alot of updates have been made over the past few months.
> 
> Flyway was upgraded along with support for java 11. The DB names were also 
> changed few weeks ago.
> 
> Check the readme for others having problems with latest Fineract 1.x on the 
> develop branch.
> 
> 
> 
> On Fri, May 15, 2020, 04:56 Sergio Junior  > wrote:
> Renaming the schema_version table to flyway_schema_history seems to have 
> worked.
> 
> Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior  > escreveu:
> Dears,
> 
> We were using the docker version from March dont know exactly which one it 
> was because theres no tags, just the "latest". 
> Now we updated the image from docker but the database is not compatible, the 
> Flyway cannot apply migrations because theres no schema history table.
> 
> Theres any way to apply the migrations?
> 
> Thanks!
> 
> 
> -- 
> Atenciosamente,
> Sergio Luiz Miziara Junior
> Tel.: (011) 8727.6447

Re: Migration to latest

[Michael Vorburger]

Sergio,

Thank you for having shared this with the developer list. Feedback like
this is a great way to contribute to the project.

This sounds like it could be due to our recent upgrade of the Flyway
library itself, see https://jira.apache.org/jira/browse/FINERACT-810. I do
find it kind of funny that a tool made to facilitate seamless database
upgrades makes a breaking non-compatible schema change itself... ;-)

I guess it would be much nicer if we could fix this to remain compatible.
Noticing how https://flywaydb.org/getstarted/how says (quote) "a database
with a single empty table called *flyway_schema_history* **by default**" to
me makes it sound like it may be possible to override and change this so
that it's like before... would someone like to look more into trying that,
testing this, and contributing a Pull Request with a solution? I've opened
new https://jira.apache.org/jira/browse/FINERACT-979 to track this.

Best,
M.
___
Michael Vorburger
http://www.vorburger.ch


On Fri, May 15, 2020 at 11:02 AM Awasum Yannick  wrote:

> Yes, alot of updates have been made over the past few months.
>
> Flyway was upgraded along with support for java 11. The DB names were also
> changed few weeks ago.
>
> Check the readme for others having problems with latest Fineract 1.x on
> the develop branch.
>
>
>
> On Fri, May 15, 2020, 04:56 Sergio Junior  wrote:
>
>> Renaming the schema_version table to flyway_schema_history seems to have
>> worked.
>>
>> Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior 
>> escreveu:
>>
>>> Dears,
>>>
>>> We were using the docker version from March dont know exactly which one
>>> it was because theres no tags, just the "latest".
>>> Now we updated the image from docker but the database is not compatible,
>>> the Flyway cannot apply migrations because theres no schema history table.
>>>
>>> Theres any way to apply the migrations?
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> Atenciosamente,
>> Sergio Luiz Miziara Junior
>> Tel.: (011) 8727.6447
>>
>

Re: Migration to latest

[Awasum Yannick]

Yes, alot of updates have been made over the past few months.

Flyway was upgraded along with support for java 11. The DB names were also
changed few weeks ago.

Check the readme for others having problems with latest Fineract 1.x on the
develop branch.



On Fri, May 15, 2020, 04:56 Sergio Junior  wrote:

> Renaming the schema_version table to flyway_schema_history seems to have
> worked.
>
> Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior 
> escreveu:
>
>> Dears,
>>
>> We were using the docker version from March dont know exactly which one
>> it was because theres no tags, just the "latest".
>> Now we updated the image from docker but the database is not compatible,
>> the Flyway cannot apply migrations because theres no schema history table.
>>
>> Theres any way to apply the migrations?
>>
>> Thanks!
>>
>
>
> --
> Atenciosamente,
> Sergio Luiz Miziara Junior
> Tel.: (011) 8727.6447
>

Re: Migration to latest

[Sergio Junior]

Renaming the schema_version table to flyway_schema_history seems to have
worked.

Em qui., 14 de mai. de 2020 às 22:57, Sergio Junior 
escreveu:

> Dears,
>
> We were using the docker version from March dont know exactly which one it
> was because theres no tags, just the "latest".
> Now we updated the image from docker but the database is not compatible,
> the Flyway cannot apply migrations because theres no schema history table.
>
> Theres any way to apply the migrations?
>
> Thanks!
>


-- 
Atenciosamente,
Sergio Luiz Miziara Junior
Tel.: (011) 8727.6447

Migration to latest

[Sergio Junior]

Dears,

We were using the docker version from March dont know exactly which one it
was because theres no tags, just the "latest".
Now we updated the image from docker but the database is not compatible,
the Flyway cannot apply migrations because theres no schema history table.

Theres any way to apply the migrations?

Thanks!