Liquibase support

[Arnold Galovics <ga...@gmail.com>]

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

Re: Liquibase support

[Arnold Galovics <ga...@gmail.com>]

Hi guys,

Just doing a follow-up on this topic. Aleks has started the release process
for 1.6.0 which means 1.7.0 things are ready to be merged into develop.
Is there a chance some of you could review the Liquibase change PR? Just
for the record, here it is: https://github.com/apache/fineract/pull/2030

Thanks!
Best,
Arnold

On Fri, Feb 11, 2022 at 9:38 AM Arnold Galovics <ga...@gmail.com>
wrote:

> 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 <ga...@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.romero@fintecheando.mx> wrote:
>>>
>>>> Alberto,
>>>>
>>>> Can you share your thoughts?
>>>>
>>>> Regards
>>>>
>>>> Victor
>>>>
>>>>
>>>>
>>>> El mar, 8 feb 2022 a las 4:19, Aleksandar Vidakovic (<
>>>> cheetah@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 <
>>>>> galovicsarnold@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 <
>>>>>> cheetah@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 <
>>>>>>> galovicsarnold@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
>>>>>>>>
>>>>>>>

Re: Liquibase support

[Arnold Galovics <ga...@gmail.com>]

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 <ga...@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.romero@fintecheando.mx> wrote:
>>
>>> Alberto,
>>>
>>> Can you share your thoughts?
>>>
>>> Regards
>>>
>>> Victor
>>>
>>>
>>>
>>> El mar, 8 feb 2022 a las 4:19, Aleksandar Vidakovic (<
>>> cheetah@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 <
>>>> galovicsarnold@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 <
>>>>> cheetah@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 <
>>>>>> galovicsarnold@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
>>>>>>>
>>>>>>

Re: Liquibase support

[Petri Tuomola <pe...@tuomola.org.INVALID>]

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 <ga...@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.romero@fintecheando.mx> wrote:
>
>> Alberto,
>>
>> Can you share your thoughts?
>>
>> Regards
>>
>> Victor
>>
>>
>>
>> El mar, 8 feb 2022 a las 4:19, Aleksandar Vidakovic (<
>> cheetah@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 <
>>> galovicsarnold@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 <
>>>> cheetah@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 <
>>>>> galovicsarnold@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
>>>>>>
>>>>>

Re: Liquibase support

[Arnold Galovics <ga...@gmail.com>]

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.romero@fintecheando.mx> wrote:

> Alberto,
>
> Can you share your thoughts?
>
> Regards
>
> Victor
>
>
>
> El mar, 8 feb 2022 a las 4:19, Aleksandar Vidakovic (<
> cheetah@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 <ga...@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 <
>>> cheetah@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 <
>>>> galovicsarnold@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
>>>>>
>>>>

Re: Liquibase support

[VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>]

Alberto,

Can you share your thoughts?

Regards

Victor



El mar, 8 feb 2022 a las 4:19, Aleksandar Vidakovic (<
cheetah@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 <ga...@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 <
>> cheetah@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 <
>>> galovicsarnold@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
>>>>
>>>

Re: Liquibase support

[Aleksandar Vidakovic <ch...@monkeysintown.com>]

... 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 <ga...@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 <
> cheetah@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 <ga...@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
>>>
>>

Re: Liquibase support

[Arnold Galovics <ga...@gmail.com>]

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 <
cheetah@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 <ga...@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
>>
>

Re: Liquibase support

[Aleksandar Vidakovic <ch...@monkeysintown.com>]

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 <ga...@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
>