You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Isaac Kamga <u2...@gmail.com> on 2019/10/20 01:02:59 UTC

Should we archive MariaDB and Data-jpa repositories ?

Happy weekend fineracters,

After migrating our RDBMS from MariaDB to PostgreSQL, Michael (CC'ed here)
suggested we stick to one RDBMS in this discussion [1] which is different
from the suggestion from Ed Cable and Vishwas Babu about using a different
RDBMS for each profile/environment.

I thought we should make a community-driven decision on this as it would
lead to us either archiving fineract-cn-mariadb [2] repository or not [3].

The fineract-cn-data-jpa [4] repository does not appear very useful ?
Should it be archived too ?

Cheers,
Isaac Kamga.

[1]
https://issues.apache.org/jira/browse/FINCN-26?focusedCommentId=16951585&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16951585
[2] https://github.com/apache/fineract-cn-mariadb/pull/9
[3]
https://github.com/apache/fineract-cn-mariadb/pull/9#issuecomment-541491341
[4] https://github.com/apache/fineract-cn-data-jpa

Re: Should we archive MariaDB and Data-jpa repositories ?

Posted by Isaac Kamga <u2...@gmail.com>.
Thank you all for your valuable comments on this topic.

I just created a Jira issue
<https://issues.apache.org/jira/browse/FINCN-190> which captures the
concerns brought up here. Anyone can now pick it up and get to work on
making database portability possible.

I hope this helps.

Cheers,
Isaac.

On Mon, Oct 21, 2019 at 12:50 PM Ed Cable <ed...@mifos.org> wrote:

> Vishwas,
>
> Thanks for responding with the more detailed context around the feedback
> you were intending to convey regarding configurability around the DB and
> not maintaining specific repositories for each DB. Your response helps
> address some of the concerns that James was bringing up in the
> other thread.
>
> I know that you don't have time personally to address the review
> comments but could you capture those in a formal JIRA issue so they don't
> get buried in this thread or the mailing list. I know that others in
> community like Victor from Fintecheando are already needing to support
> Oracle database so perhaps a member of his team could try to address the
> suggestions you have made.
>
> @Victor Manuel Romero Rodriguez <vi...@fintecheando.mx> Did you
> see Vishwas' suggestions above? Is this something your team could pick up?
> How have you and your team gone about the connection to Oracle at the
> moment?
>
> I think we're all in agreement around reducing maintenance burden and
> development complexity but through only minor work at this stage, we can
> achieve better database portability and ease of integration/deployment for
> implementers, I would suggest we do that before closing out on this
> discussion.
>
> Ed
>
> On Mon, Oct 21, 2019 at 8:22 AM Vishwas Babu A J <vi...@apache.org>
> wrote:
>
>> Hello All,
>>
>> Adding some context regarding the review comments made on the approach
>> taken for the MySQL to PostgreSQL migration during a code walkthrough with
>> Ed and Isaac.
>> In the context of each microservice (take accounting for example) , the
>> changes required are encapsulated in
>> https://github.com/apache/fineract-cn-accounting/commit/9c23639f71981e3dc74a6351df35d9af624ff0d6.
>> At a high level , these changes are limited to
>> 1) Updating dependencies to the DB specific library (i.e the equivalent
>> of https://github.com/apache/fineract-cn-mariadb) in the gradle build
>> and the connection settings2) Updating a bunch of imports related to
>> classes used from the DB specific library (essentially replacing each
>> occurrence of *.mariadb.config.EnableMariaDB with
>> *.postgresql.config.EnablePostgreSQL,  MariaDBInitializer with
>> PostgreSQLInitializer etc)3) Tweaking Flyway SQL scripts to work on the
>> particular database engine
>> I would have preferred if
>> (a) Before doing (2) , we had refactored
>> https://github.com/apache/fineract-cn-mariadb to be the reference
>> implementation (generalize symbols likeMariaDBInitializer ->
>> RDBMSInitializer etc) and then have
>> https://github.com/apache/fineract-cn-postgresql implement the same
>> specification.(b) Setup build profiles on each microservice to pick up the
>> right DB dependency (1) and set the root context for SQL scripts picked by
>> Flyway (3)
>> The goal being that at the end of the exercise, we would have a POC to
>> run with both the existing MySQL and the new PostgreSQL libraries based on
>> the build profile selected.
>> Going forward, the community would only ship and maintain PostgreSQL as
>> the default RDBMs. However, those interested in supporting alternate
>> databases could quickly have an initial version running on the database of
>> their choice without the need to tweak any code other than gradle property
>> files. They could also supply alternate DB connectors (implementing the
>> fineract-cn-mariadb RI) and flyway scripts which could be hosted on our /
>> related community repositories.
>>
>> The business need behind this being the preferred approach was as follows:
>> As long as we are thinking of small MFI's, co-operatives , banks in
>> smaller countries etc who are comfortable working on SaaS models etc, any
>> database works. However, given the complexity of Fineract CN , I would
>> assume that it would eventually be targeted towards mid size / larger banks
>> who tend to be very opinionated on their tech stack.
>> For example, in the company I worked for-> We came across reputed
>> financial institutes who were simply unwilling to use MySQL forks as their
>> OLTP database even if we met all the required performance benchmarks ->
>> Over the years, we have built up a lot of expertise in fine-tuning MySQL
>> replacement databases for high concurrency scenarios. Think Percona for
>> banks having challenging performance benchmarks for 4 million active
>> clients etc, skills which do not easily translate to tuning PostgreSQL for
>> similar loads.
>> This being said, I don't really have any issue with any library being
>> archived. Mainly because talk is cheap and I currently cannot commit the
>> time to addressing these review comments.
>>
>> On 2019/10/21 08:58:28, Isaac Kamga <u2...@gmail.com> wrote:
>> > Thanks for your input Michael and Juhan,
>> >
>> > I agree with you that adding more complexity to Fineract CN would slow
>> down
>> > development even further so sticking to one RDBMs is better.
>> >
>> > Cheers,
>> > Isaac Kamga.
>> >
>> > On Sun, Oct 20, 2019 at 11:16 PM Juhan Aasaru <aa...@gmail.com> wrote:
>> >
>> > > Hi!
>> > >
>> > > I agree with Michael on this.
>> > > We have very limited resources - let's spend them on work that gives
>> back
>> > > the most value.
>> > >
>> > > Also we should keep in mind that if we add complexity to the system
>> the
>> > > slower the development speed is going to be.
>> > > And more complexity sets the bar higher for any newcomer to come in
>> and
>> > > start contributing.
>> > >
>> > > fineract-cn-data-jpa is not used by any library so I think we should
>> > > archive this as well.
>> > >
>> > > Also archiving repository doesn't mean it is deleted. If we change our
>> > > mind later then we can always unarchive it
>> > > at any point.
>> > >
>> > > Juhan
>> > >
>> > > Kontakt Michael Vorburger (<mi...@vorburger.ch>) kirjutas kuupäeval
>> P, 20.
>> > > oktoober 2019 kell 14:31:
>> > >
>> > >> On Sun, 20 Oct 2019, 03:03 Isaac Kamga, <u2...@gmail.com> wrote:
>> > >>
>> > >>> Happy weekend fineracters,
>> > >>>
>> > >>> After migrating our RDBMS from MariaDB to PostgreSQL, Michael (CC'ed
>> > >>> here) suggested we stick to one RDBMS in this discussion [1]
>> > >>>
>> > >>
>> > >> so my PoV on this is just that in any universe where resources are
>> > >> limited (such as ours, excluding possible parallel universes),
>> focusing
>> > >> energies e.g. on a single FLOSS DB makes sense.
>> > >>
>> > >> I'm sure both MySQL (MariaDB really, but that's another
>> discussion..) and
>> > >> Postgres are both great, with the proper tuning - which I would
>> focus on
>> > >> doing for one of them, not twice.
>> > >>
>> > >> which is different from the suggestion from Ed Cable and Vishwas Babu
>> > >>> about using a different RDBMS for each profile/environment.
>> > >>>
>> > >>> I thought we should make a community-driven decision on this as it
>> would
>> > >>> lead to us either archiving fineract-cn-mariadb [2] repository or
>> not [3].
>> > >>>
>> > >>> The fineract-cn-data-jpa [4] repository does not appear very useful
>> ?
>> > >>> Should it be archived too ?
>> > >>>
>> > >>> Cheers,
>> > >>> Isaac Kamga.
>> > >>>
>> > >>> [1]
>> > >>>
>> https://issues.apache.org/jira/browse/FINCN-26?focusedCommentId=16951585&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16951585
>> > >>> [2] https://github.com/apache/fineract-cn-mariadb/pull/9
>> > >>> [3]
>> > >>>
>> https://github.com/apache/fineract-cn-mariadb/pull/9#issuecomment-541491341
>> > >>> [4] https://github.com/apache/fineract-cn-data-jpa
>> > >>>
>> > >>
>> >
>>
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
>
>

Re: Should we archive MariaDB and Data-jpa repositories ?

Posted by Ed Cable <ed...@mifos.org>.
Vishwas,

Thanks for responding with the more detailed context around the feedback
you were intending to convey regarding configurability around the DB and
not maintaining specific repositories for each DB. Your response helps
address some of the concerns that James was bringing up in the
other thread.

I know that you don't have time personally to address the review
comments but could you capture those in a formal JIRA issue so they don't
get buried in this thread or the mailing list. I know that others in
community like Victor from Fintecheando are already needing to support
Oracle database so perhaps a member of his team could try to address the
suggestions you have made.

@Victor Manuel Romero Rodriguez <vi...@fintecheando.mx> Did you see
Vishwas' suggestions above? Is this something your team could pick up?
How have you and your team gone about the connection to Oracle at the
moment?

I think we're all in agreement around reducing maintenance burden and
development complexity but through only minor work at this stage, we can
achieve better database portability and ease of integration/deployment for
implementers, I would suggest we do that before closing out on this
discussion.

Ed

On Mon, Oct 21, 2019 at 8:22 AM Vishwas Babu A J <vi...@apache.org>
wrote:

> Hello All,
>
> Adding some context regarding the review comments made on the approach
> taken for the MySQL to PostgreSQL migration during a code walkthrough with
> Ed and Isaac.
> In the context of each microservice (take accounting for example) , the
> changes required are encapsulated in
> https://github.com/apache/fineract-cn-accounting/commit/9c23639f71981e3dc74a6351df35d9af624ff0d6.
> At a high level , these changes are limited to
> 1) Updating dependencies to the DB specific library (i.e the equivalent of
> https://github.com/apache/fineract-cn-mariadb) in the gradle build and
> the connection settings2) Updating a bunch of imports related to classes
> used from the DB specific library (essentially replacing each occurrence of
> *.mariadb.config.EnableMariaDB with *.postgresql.config.EnablePostgreSQL,
>  MariaDBInitializer with PostgreSQLInitializer etc)3) Tweaking Flyway SQL
> scripts to work on the particular database engine
> I would have preferred if
> (a) Before doing (2) , we had refactored
> https://github.com/apache/fineract-cn-mariadb to be the reference
> implementation (generalize symbols likeMariaDBInitializer ->
> RDBMSInitializer etc) and then have
> https://github.com/apache/fineract-cn-postgresql implement the same
> specification.(b) Setup build profiles on each microservice to pick up the
> right DB dependency (1) and set the root context for SQL scripts picked by
> Flyway (3)
> The goal being that at the end of the exercise, we would have a POC to run
> with both the existing MySQL and the new PostgreSQL libraries based on the
> build profile selected.
> Going forward, the community would only ship and maintain PostgreSQL as
> the default RDBMs. However, those interested in supporting alternate
> databases could quickly have an initial version running on the database of
> their choice without the need to tweak any code other than gradle property
> files. They could also supply alternate DB connectors (implementing the
> fineract-cn-mariadb RI) and flyway scripts which could be hosted on our /
> related community repositories.
>
> The business need behind this being the preferred approach was as follows:
> As long as we are thinking of small MFI's, co-operatives , banks in
> smaller countries etc who are comfortable working on SaaS models etc, any
> database works. However, given the complexity of Fineract CN , I would
> assume that it would eventually be targeted towards mid size / larger banks
> who tend to be very opinionated on their tech stack.
> For example, in the company I worked for-> We came across reputed
> financial institutes who were simply unwilling to use MySQL forks as their
> OLTP database even if we met all the required performance benchmarks ->
> Over the years, we have built up a lot of expertise in fine-tuning MySQL
> replacement databases for high concurrency scenarios. Think Percona for
> banks having challenging performance benchmarks for 4 million active
> clients etc, skills which do not easily translate to tuning PostgreSQL for
> similar loads.
> This being said, I don't really have any issue with any library being
> archived. Mainly because talk is cheap and I currently cannot commit the
> time to addressing these review comments.
>
> On 2019/10/21 08:58:28, Isaac Kamga <u2...@gmail.com> wrote:
> > Thanks for your input Michael and Juhan,
> >
> > I agree with you that adding more complexity to Fineract CN would slow
> down
> > development even further so sticking to one RDBMs is better.
> >
> > Cheers,
> > Isaac Kamga.
> >
> > On Sun, Oct 20, 2019 at 11:16 PM Juhan Aasaru <aa...@gmail.com> wrote:
> >
> > > Hi!
> > >
> > > I agree with Michael on this.
> > > We have very limited resources - let's spend them on work that gives
> back
> > > the most value.
> > >
> > > Also we should keep in mind that if we add complexity to the system the
> > > slower the development speed is going to be.
> > > And more complexity sets the bar higher for any newcomer to come in and
> > > start contributing.
> > >
> > > fineract-cn-data-jpa is not used by any library so I think we should
> > > archive this as well.
> > >
> > > Also archiving repository doesn't mean it is deleted. If we change our
> > > mind later then we can always unarchive it
> > > at any point.
> > >
> > > Juhan
> > >
> > > Kontakt Michael Vorburger (<mi...@vorburger.ch>) kirjutas kuupäeval P,
> 20.
> > > oktoober 2019 kell 14:31:
> > >
> > >> On Sun, 20 Oct 2019, 03:03 Isaac Kamga, <u2...@gmail.com> wrote:
> > >>
> > >>> Happy weekend fineracters,
> > >>>
> > >>> After migrating our RDBMS from MariaDB to PostgreSQL, Michael (CC'ed
> > >>> here) suggested we stick to one RDBMS in this discussion [1]
> > >>>
> > >>
> > >> so my PoV on this is just that in any universe where resources are
> > >> limited (such as ours, excluding possible parallel universes),
> focusing
> > >> energies e.g. on a single FLOSS DB makes sense.
> > >>
> > >> I'm sure both MySQL (MariaDB really, but that's another discussion..)
> and
> > >> Postgres are both great, with the proper tuning - which I would focus
> on
> > >> doing for one of them, not twice.
> > >>
> > >> which is different from the suggestion from Ed Cable and Vishwas Babu
> > >>> about using a different RDBMS for each profile/environment.
> > >>>
> > >>> I thought we should make a community-driven decision on this as it
> would
> > >>> lead to us either archiving fineract-cn-mariadb [2] repository or
> not [3].
> > >>>
> > >>> The fineract-cn-data-jpa [4] repository does not appear very useful ?
> > >>> Should it be archived too ?
> > >>>
> > >>> Cheers,
> > >>> Isaac Kamga.
> > >>>
> > >>> [1]
> > >>>
> https://issues.apache.org/jira/browse/FINCN-26?focusedCommentId=16951585&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16951585
> > >>> [2] https://github.com/apache/fineract-cn-mariadb/pull/9
> > >>> [3]
> > >>>
> https://github.com/apache/fineract-cn-mariadb/pull/9#issuecomment-541491341
> > >>> [4] https://github.com/apache/fineract-cn-data-jpa
> > >>>
> > >>
> >
>


-- 
*Ed Cable*
President/CEO, Mifos Initiative
edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos>  <http://www.twitter.com/mifos>

Re: Should we archive MariaDB and Data-jpa repositories ?

Posted by Vishwas Babu A J <vi...@apache.org>.
Hello All,

Adding some context regarding the review comments made on the approach taken for the MySQL to PostgreSQL migration during a code walkthrough with Ed and Isaac.
In the context of each microservice (take accounting for example) , the changes required are encapsulated in https://github.com/apache/fineract-cn-accounting/commit/9c23639f71981e3dc74a6351df35d9af624ff0d6. At a high level , these changes are limited to
1) Updating dependencies to the DB specific library (i.e the equivalent of https://github.com/apache/fineract-cn-mariadb) in the gradle build and the connection settings2) Updating a bunch of imports related to classes used from the DB specific library (essentially replacing each occurrence of *.mariadb.config.EnableMariaDB with *.postgresql.config.EnablePostgreSQL,  MariaDBInitializer with PostgreSQLInitializer etc)3) Tweaking Flyway SQL scripts to work on the particular database engine
I would have preferred if
(a) Before doing (2) , we had refactored https://github.com/apache/fineract-cn-mariadb to be the reference implementation (generalize symbols likeMariaDBInitializer -> RDBMSInitializer etc) and then have https://github.com/apache/fineract-cn-postgresql implement the same specification.(b) Setup build profiles on each microservice to pick up the right DB dependency (1) and set the root context for SQL scripts picked by Flyway (3)
The goal being that at the end of the exercise, we would have a POC to run with both the existing MySQL and the new PostgreSQL libraries based on the build profile selected. 
Going forward, the community would only ship and maintain PostgreSQL as the default RDBMs. However, those interested in supporting alternate databases could quickly have an initial version running on the database of their choice without the need to tweak any code other than gradle property files. They could also supply alternate DB connectors (implementing the fineract-cn-mariadb RI) and flyway scripts which could be hosted on our / related community repositories.

The business need behind this being the preferred approach was as follows:
As long as we are thinking of small MFI's, co-operatives , banks in smaller countries etc who are comfortable working on SaaS models etc, any database works. However, given the complexity of Fineract CN , I would assume that it would eventually be targeted towards mid size / larger banks who tend to be very opinionated on their tech stack. 
For example, in the company I worked for-> We came across reputed financial institutes who were simply unwilling to use MySQL forks as their OLTP database even if we met all the required performance benchmarks -> Over the years, we have built up a lot of expertise in fine-tuning MySQL replacement databases for high concurrency scenarios. Think Percona for banks having challenging performance benchmarks for 4 million active clients etc, skills which do not easily translate to tuning PostgreSQL for similar loads.
This being said, I don't really have any issue with any library being archived. Mainly because talk is cheap and I currently cannot commit the time to addressing these review comments.

On 2019/10/21 08:58:28, Isaac Kamga <u2...@gmail.com> wrote: 
> Thanks for your input Michael and Juhan,
> 
> I agree with you that adding more complexity to Fineract CN would slow down
> development even further so sticking to one RDBMs is better.
> 
> Cheers,
> Isaac Kamga.
> 
> On Sun, Oct 20, 2019 at 11:16 PM Juhan Aasaru <aa...@gmail.com> wrote:
> 
> > Hi!
> >
> > I agree with Michael on this.
> > We have very limited resources - let's spend them on work that gives back
> > the most value.
> >
> > Also we should keep in mind that if we add complexity to the system the
> > slower the development speed is going to be.
> > And more complexity sets the bar higher for any newcomer to come in and
> > start contributing.
> >
> > fineract-cn-data-jpa is not used by any library so I think we should
> > archive this as well.
> >
> > Also archiving repository doesn't mean it is deleted. If we change our
> > mind later then we can always unarchive it
> > at any point.
> >
> > Juhan
> >
> > Kontakt Michael Vorburger (<mi...@vorburger.ch>) kirjutas kuupäeval P, 20.
> > oktoober 2019 kell 14:31:
> >
> >> On Sun, 20 Oct 2019, 03:03 Isaac Kamga, <u2...@gmail.com> wrote:
> >>
> >>> Happy weekend fineracters,
> >>>
> >>> After migrating our RDBMS from MariaDB to PostgreSQL, Michael (CC'ed
> >>> here) suggested we stick to one RDBMS in this discussion [1]
> >>>
> >>
> >> so my PoV on this is just that in any universe where resources are
> >> limited (such as ours, excluding possible parallel universes), focusing
> >> energies e.g. on a single FLOSS DB makes sense.
> >>
> >> I'm sure both MySQL (MariaDB really, but that's another discussion..) and
> >> Postgres are both great, with the proper tuning - which I would focus on
> >> doing for one of them, not twice.
> >>
> >> which is different from the suggestion from Ed Cable and Vishwas Babu
> >>> about using a different RDBMS for each profile/environment.
> >>>
> >>> I thought we should make a community-driven decision on this as it would
> >>> lead to us either archiving fineract-cn-mariadb [2] repository or not [3].
> >>>
> >>> The fineract-cn-data-jpa [4] repository does not appear very useful ?
> >>> Should it be archived too ?
> >>>
> >>> Cheers,
> >>> Isaac Kamga.
> >>>
> >>> [1]
> >>> https://issues.apache.org/jira/browse/FINCN-26?focusedCommentId=16951585&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16951585
> >>> [2] https://github.com/apache/fineract-cn-mariadb/pull/9
> >>> [3]
> >>> https://github.com/apache/fineract-cn-mariadb/pull/9#issuecomment-541491341
> >>> [4] https://github.com/apache/fineract-cn-data-jpa
> >>>
> >>
>

Re: Should we archive MariaDB and Data-jpa repositories ?

Posted by Isaac Kamga <u2...@gmail.com>.
Thanks for your input Michael and Juhan,

I agree with you that adding more complexity to Fineract CN would slow down
development even further so sticking to one RDBMs is better.

Cheers,
Isaac Kamga.

On Sun, Oct 20, 2019 at 11:16 PM Juhan Aasaru <aa...@gmail.com> wrote:

> Hi!
>
> I agree with Michael on this.
> We have very limited resources - let's spend them on work that gives back
> the most value.
>
> Also we should keep in mind that if we add complexity to the system the
> slower the development speed is going to be.
> And more complexity sets the bar higher for any newcomer to come in and
> start contributing.
>
> fineract-cn-data-jpa is not used by any library so I think we should
> archive this as well.
>
> Also archiving repository doesn't mean it is deleted. If we change our
> mind later then we can always unarchive it
> at any point.
>
> Juhan
>
> Kontakt Michael Vorburger (<mi...@vorburger.ch>) kirjutas kuupäeval P, 20.
> oktoober 2019 kell 14:31:
>
>> On Sun, 20 Oct 2019, 03:03 Isaac Kamga, <u2...@gmail.com> wrote:
>>
>>> Happy weekend fineracters,
>>>
>>> After migrating our RDBMS from MariaDB to PostgreSQL, Michael (CC'ed
>>> here) suggested we stick to one RDBMS in this discussion [1]
>>>
>>
>> so my PoV on this is just that in any universe where resources are
>> limited (such as ours, excluding possible parallel universes), focusing
>> energies e.g. on a single FLOSS DB makes sense.
>>
>> I'm sure both MySQL (MariaDB really, but that's another discussion..) and
>> Postgres are both great, with the proper tuning - which I would focus on
>> doing for one of them, not twice.
>>
>> which is different from the suggestion from Ed Cable and Vishwas Babu
>>> about using a different RDBMS for each profile/environment.
>>>
>>> I thought we should make a community-driven decision on this as it would
>>> lead to us either archiving fineract-cn-mariadb [2] repository or not [3].
>>>
>>> The fineract-cn-data-jpa [4] repository does not appear very useful ?
>>> Should it be archived too ?
>>>
>>> Cheers,
>>> Isaac Kamga.
>>>
>>> [1]
>>> https://issues.apache.org/jira/browse/FINCN-26?focusedCommentId=16951585&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16951585
>>> [2] https://github.com/apache/fineract-cn-mariadb/pull/9
>>> [3]
>>> https://github.com/apache/fineract-cn-mariadb/pull/9#issuecomment-541491341
>>> [4] https://github.com/apache/fineract-cn-data-jpa
>>>
>>

Re: Should we archive MariaDB and Data-jpa repositories ?

Posted by Juhan Aasaru <aa...@gmail.com>.
Hi!

I agree with Michael on this.
We have very limited resources - let's spend them on work that gives back
the most value.

Also we should keep in mind that if we add complexity to the system the
slower the development speed is going to be.
And more complexity sets the bar higher for any newcomer to come in and
start contributing.

fineract-cn-data-jpa is not used by any library so I think we should
archive this as well.

Also archiving repository doesn't mean it is deleted. If we change our mind
later then we can always unarchive it
at any point.

Juhan

Kontakt Michael Vorburger (<mi...@vorburger.ch>) kirjutas kuupäeval P, 20.
oktoober 2019 kell 14:31:

> On Sun, 20 Oct 2019, 03:03 Isaac Kamga, <u2...@gmail.com> wrote:
>
>> Happy weekend fineracters,
>>
>> After migrating our RDBMS from MariaDB to PostgreSQL, Michael (CC'ed
>> here) suggested we stick to one RDBMS in this discussion [1]
>>
>
> so my PoV on this is just that in any universe where resources are limited
> (such as ours, excluding possible parallel universes), focusing energies
> e.g. on a single FLOSS DB makes sense.
>
> I'm sure both MySQL (MariaDB really, but that's another discussion..) and
> Postgres are both great, with the proper tuning - which I would focus on
> doing for one of them, not twice.
>
> which is different from the suggestion from Ed Cable and Vishwas Babu
>> about using a different RDBMS for each profile/environment.
>>
>> I thought we should make a community-driven decision on this as it would
>> lead to us either archiving fineract-cn-mariadb [2] repository or not [3].
>>
>> The fineract-cn-data-jpa [4] repository does not appear very useful ?
>> Should it be archived too ?
>>
>> Cheers,
>> Isaac Kamga.
>>
>> [1]
>> https://issues.apache.org/jira/browse/FINCN-26?focusedCommentId=16951585&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16951585
>> [2] https://github.com/apache/fineract-cn-mariadb/pull/9
>> [3]
>> https://github.com/apache/fineract-cn-mariadb/pull/9#issuecomment-541491341
>> [4] https://github.com/apache/fineract-cn-data-jpa
>>
>

Re: Should we archive MariaDB and Data-jpa repositories ?

Posted by Michael Vorburger <mi...@vorburger.ch>.
On Sun, 20 Oct 2019, 03:03 Isaac Kamga, <u2...@gmail.com> wrote:

> Happy weekend fineracters,
>
> After migrating our RDBMS from MariaDB to PostgreSQL, Michael (CC'ed here)
> suggested we stick to one RDBMS in this discussion [1]
>

so my PoV on this is just that in any universe where resources are limited
(such as ours, excluding possible parallel universes), focusing energies
e.g. on a single FLOSS DB makes sense.

I'm sure both MySQL (MariaDB really, but that's another discussion..) and
Postgres are both great, with the proper tuning - which I would focus on
doing for one of them, not twice.

which is different from the suggestion from Ed Cable and Vishwas Babu about
> using a different RDBMS for each profile/environment.
>
> I thought we should make a community-driven decision on this as it would
> lead to us either archiving fineract-cn-mariadb [2] repository or not [3].
>
> The fineract-cn-data-jpa [4] repository does not appear very useful ?
> Should it be archived too ?
>
> Cheers,
> Isaac Kamga.
>
> [1]
> https://issues.apache.org/jira/browse/FINCN-26?focusedCommentId=16951585&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16951585
> [2] https://github.com/apache/fineract-cn-mariadb/pull/9
> [3]
> https://github.com/apache/fineract-cn-mariadb/pull/9#issuecomment-541491341
> [4] https://github.com/apache/fineract-cn-data-jpa
>