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