Hi Petri, Sure thing.
As I wrote in the first email, one of the major motivations towards Liquibase is the ability to seamlessly support multiple databases in terms of schema creation and initial data inserts. This gets extremely important if Fineract will support for example PostgreSQL in addition to the current MySQL support. Unfortunately MySQL and PostgreSQL have differences in how to do those things in certain cases and with plain SQL, it could be cumbersome to maintain 2 types of SQL scripts, one for MySQL and one for PostgreSQL. With Liquibase we can forget about plain SQL for schema management and use a generic format that applies to multiple databases. However, if there's a need of using a plan SQL, we can do that too in Liquibase but with a more robust solution (using different contexts to apply certain parts of the changesets). Plus, there are a couple other benefits which I don't want to copy paste here: https://www.liquibase.com/liquibase-vs-flyway Although, I've gotta say Liquibase preconditions make database schema migrations really easy. I've used them quite extensively on other projects and saved a lot of time when switching back and forth between service versions. Does that make sense? Best, Arnold On Fri, Feb 11, 2022 at 1:21 AM Petri Tuomola <pe...@tuomola.org.invalid> wrote: > Hi Arnold > > Looks like a smooth transition. Can you share what are the benefits we > should expect to get from Liquibase over Flyway? > > Cheers > Petri > > On Fri, Feb 11, 2022, 03:14 Arnold Galovics <galovicsarn...@gmail.com> > wrote: > >> Hi everybody, >> >> Just wanted to let you know that the PR is ready for the Flyway to >> Liquibase change. https://github.com/apache/fineract/pull/2030 >> The change is planned to be included only in 1.7 and not targeted for 1.6. >> >> I'd like to assure everybody that the forward upgrade is going to be >> fully automatic from Fineract 1.6 to Fineract 1.7, there's no need for >> manual changes. >> >> The automatic upgrade works in 3 different ways depending on the scenario: >> - If the database is completely empty, it's going to apply all changesets >> from the Liquibase changelogs >> - If the database contains the changes from the last Flyway migration >> scripts included in Fineract 1.6. In that case, a seamless upgrade is going >> to happen to Liquibase >> - If the database contains Flyway changes but it's not running the latest >> migration scripts from 1.6 - i.e. the Fineract version being ran is >> pre-1.6. In that case the application startup will fail, notifying the >> operator in the logs that first they shall upgrade to 1.6 and then to 1.7 >> >> Let me know if you have any thoughts on the changes. >> >> Best, >> Arnold >> >> On Tue, Feb 8, 2022 at 3:33 PM VICTOR MANUEL ROMERO RODRIGUEZ < >> victor.rom...@fintecheando.mx> wrote: >> >>> Alberto, >>> >>> Can you share your thoughts? >>> >>> Regards >>> >>> Victor >>> >>> >>> >>> El mar, 8 feb 2022 a las 4:19, Aleksandar Vidakovic (< >>> chee...@monkeysintown.com>) escribió: >>> >>>> ... YAML, XML or JSON... all good for me... in the end very easy to >>>> transform with Jackson in a one liner if someone needs a different >>>> format... >>>> >>>> So, have no preference here... let's see what the community has >>>> to say... >>>> >>>> Cheers >>>> >>>> On Tue, Feb 8, 2022 at 10:56 AM Arnold Galovics < >>>> galovicsarn...@gmail.com> wrote: >>>> >>>>> Hi Aleks, >>>>> >>>>> Good to know. >>>>> >>>>> Any preference for YAML versus XML format? >>>>> >>>>> Best, >>>>> Arnold >>>>> >>>>> On Tue, Feb 8, 2022 at 10:43 AM Aleksandar Vidakovic < >>>>> chee...@monkeysintown.com> wrote: >>>>> >>>>>> Hi Arnold, >>>>>> >>>>>> ... personally, I am looking forward to seeing this one happen... >>>>>> Postgres support is one of the things that I hear people requesting more >>>>>> and more often. And having used Liquibase myself in other projects, I >>>>>> have >>>>>> to say that I find it a lot easier to use and much cleaner. One thing >>>>>> that >>>>>> I could create relatively easily based on Liquibase changeset files (in >>>>>> this case I used YAML): I've created a little command line tool with >>>>>> JBang >>>>>> to generate PlantUML ERD diagrams... something that is a lot harder to >>>>>> achieve with plain DDL scripts and Flyway. >>>>>> >>>>>> I agree to include this one after 1.6... that gives us some time to >>>>>> hash out backward compatibility (or not) and figure out how to make the >>>>>> transition as easy as possible for everyone. >>>>>> >>>>>> +1 >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Aleks >>>>>> >>>>>> On Tue, Feb 8, 2022 at 10:08 AM Arnold Galovics < >>>>>> galovicsarn...@gmail.com> wrote: >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I was scanning through some tickets and found FINERACT-984 >>>>>>> <https://issues.apache.org/jira/browse/FINERACT-984>: Postgres >>>>>>> support. >>>>>>> >>>>>>> I'm glad this has been brought up already. I thought about some >>>>>>> potential paths forward to support Postgres in Fineract, let me explain. >>>>>>> >>>>>>> First of all, I've gotta say Postgres would be a great addition to >>>>>>> the current Fineract project because - at least from my experience - >>>>>>> Postgres often outperforms MySQL performance-wise. At one of my previous >>>>>>> projects - which was a completely different product from Fineract - we >>>>>>> used >>>>>>> AWS cloud to deploy the application and we were planning to use AWS >>>>>>> Aurora >>>>>>> to boost the performance but we weren't sure whether AWS Aurora MySQL or >>>>>>> Aurora PostgreSQL is the way to go, so we decided to measure it. Aurora >>>>>>> Postgre was way better than Aurora MySQL in terms of performance but I >>>>>>> can't really share numbers. >>>>>>> >>>>>>> With that said, the first step in my opinion would be to try to do >>>>>>> database-independent schema migrations for which we could use Liquibase >>>>>>> instead of Flyway. >>>>>>> >>>>>>> With Liquibase we could write the schemas in a single format and in >>>>>>> the future apply to either MySQL or PostgreSQL. In addition, Liquibase >>>>>>> also >>>>>>> supports native SQL migrations so we are not losing any functionality. >>>>>>> >>>>>>> I'm happy to take this work up and make the necessary changes to >>>>>>> Fineract. >>>>>>> >>>>>>> Note: I'm not targeting 1.6 with this change but a later release. >>>>>>> Note2: I've created a ticket as well to track this. FINERACT-1498 >>>>>>> <https://issues.apache.org/jira/browse/FINERACT-1498> >>>>>>> >>>>>>> Let me know your thoughts. >>>>>>> >>>>>>> Best, >>>>>>> Arnold >>>>>>> >>>>>>
