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 >>>> >>> >>
