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: [Mifos-Fineract] Failing Build.

[Michael Vorburger]

Collins,

On Sat, May 16, 2020 at 2:54 PM collins chuwa 
wrote:

> Greetings devs,
>
> I have build failed and integration test failed as a result of
> AmazonS3Client been deprecated. I don’t know if this has been solved or
> not. Using AmazonS3ClientBuilder also fails.
>

https://github.com/apache/fineract/pull/893 fixed that, it's already
merged, you must have cloned just before, just pull and it's fine now.

M.


> --
> Thanks
> Collins C. Wandji
> No: +237672965154
>

[Mifos-Fineract] Failing Build.

[collins chuwa]

Greetings devs,

I have build failed and integration test failed as a result of
AmazonS3Client been deprecated. I don’t know if this has been solved or
not. Using AmazonS3ClientBuilder also fails.

-- 
Thanks
Collins C. Wandji
No: +237672965154