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 < [email protected]> 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 <[email protected]> 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 <[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 >>>>>>>>>> >>>>>>>>> >>>>>>>> > -- Atenciosamente, Sergio Luiz Miziara Junior Tel.: (011) 8727.6447
