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 <[email protected]> wrote: > On Sat, May 16, 2020 at 2:19 AM Sergio Junior <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 < >>>>>>>>> [email protected]> 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 >>>>>>>>> >>>>>>>> >>>>>>>
