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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 (<[email protected]>) kirjutas kuupäeval >> P, 20. >> > > oktoober 2019 kell 14:31: >> > > >> > >> On Sun, 20 Oct 2019, 03:03 Isaac Kamga, <[email protected]> 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 > [email protected] | 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> > >
