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

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