Hello devs, Just thought I should remind the community about why these migrations are necessary.
The rationale behind migrating the ORM from Hibernate is that Hibernate ORM's license[1] falls under the ASF's Category X[1]. Not complying to the ASF's licensing requirements is a sure-fire method to never getting an official release for Fineract CN. Does anyone think there's another way around these ? Cheers, Isaac Kamga. [1] https://hibernate.org/community/license/ [2] https://www.apache.org/legal/resolved.html On Tue, Jul 9, 2019 at 11:08 PM Victor Manuel Romero Rodriguez < [email protected]> wrote: > Hello > > I will give my own opinions, by the way I don't work for any company > mentioned here :) > > For short: > > *I will keep using using Hibernate because it has advantages over the > others ORM listed. * > > > TL/TR > > The value of the core are the transactions recorded with confidence in a > Structured Database, the reliability of the Database is important, > customers can have their balances, their loans, investments, charges. The > audit guys will be happy to find in our journals the expected information. > The authorities will receive the reports that extract the information. > > Example: > > I got the source code of Fineract/Fineract-CN/Mifos and for some reason > the DataTable is not enough so then I need to modify the code... but I > don't not anything about the ORM technology,wait a minute I have some bucks > to pay a course at: > > Udemy (search results) > > 252 results for hibernate > 0 results for EclipseLink > 0 results for OpenJPA > 0 results for DataNucleus > > Ok, well now it is time to find some references in Google search engine > and learn about the ORM technology that Fineract/Fineract-CN/Mifos X uses > > Search results > > 2,350,000 hibernate > 138,000 OpenJPA > 74,900 EclipseLink > 15,400 DataNucleus > > Ok let's try to find the source code, have some references, samples (ok > just to learn, not to reuse because we can keep that in mind and later > affect the Open Source). > > Github (search results) > > 44,123 repositories hibernate > 478 repositories Eclipselink > 108 repositories OpenJPA > 142 repositories datanucleus > > After that I have touched the code and something goes wrong... yes, the > dev list of the ORM Technology is the first option, but what about to ask > to everybody at > > StackOverflow (search results) > > 78,304 Hibernate > 500 datanucleus > 500 openjpa (coincidence?) > 500 eclipselink (OK NO, StackOverflow has something strange in its search > engine) > > I consider that if the ORM technology is a MUST to be migrated, the ORM > team must be invited, involved, exchange experiences to feel the same pain > and help because it will benefit both projects. > > Regards > > Victor > On 7/1/19 1:47 a. m., Awasum Yannick wrote: > > Hi Graham, > > +1 EclipseLink as its supported by spring 4.x and latest spring versions > and compatible with Apache license. Our upgrade to Spring 5.x or 6.x will > be easier. > > We dont want to build and maintain our own integration of OpenJPA with > Spring 5 or 6 in the future. > > On Mon, Jul 1, 2019 at 7:40 AM Juhan Aasaru <[email protected]> wrote: > >> Hi! >> >> Good job starting the discussion. >> Based on your arguments I also see EclipseLink as the best solution. >> I also found one more argument for using EclipseLink - it supports >> multi-tenancy: >> >> https://www.eclipse.org/eclipselink/documentation/2.7/solutions/multitenancy.htm#CHDBJCJA >> >> Juhan >> >> Kontakt Ebenezer Graham (<[email protected]>) kirjutas >> kuupäeval E, 1. juuli 2019 kell 07:09: >> >>> Hello Devs, >>> >>> I have started this thread to discuss the JPA implementation to adopt as >>> we work towards making Fineract CN Apache compliant as well as to ensure >>> that we are all aligned as a community. >>> >>> I am currently working on the migration to OpenJPA as my GSoC project. >>> However, a number of red flags as well and requests from other community >>> members has made it critical to start this thread. >>> >>> As most of you know, we can't use Hibernate as it's not compliant >>> therefore, it's essential that we migrate to an equally good ORM. >>> >>> *Our options:* >>> 1. EclipseLink - EPL 1.0 & BSD >>> 2. OpenJPA - Apache 2.0 >>> 3. DataNucleus - Apache 2.0 >>> >>> Not recommended >>> 4. iBatic - Apache 2.0 (still functional but retired >>> https://ibatis.apache.org/) >>> 5. TopLink - CDDL (category B license, and simply extend EclipseLink) >>> >>> I used the following criteria in the following order of priority. >>> 1. License >>> 2. Implementation's performance with respect to PostgreSQL >>> 3. Support in Spring as well as ORM Documentation >>> 4. Project Maturity >>> >>> Right off the bat, I suggest the adoption of EclipseLink >>> <https://wiki.eclipse.org/EclipseLink> based on new insights >>> discovered, re-evaluation of our options, and compatibility issues >>> discovered whiles migrating to OpenJPA. >>> >>> *Why EclipseLink? * >>> According to JPA Performance benchmark - >>> http://www.jpab.org/All/All/All.html EclipseLink is the Most Efficient >>> ORM (amongst our valid options) when persisting to PostgreSQL and even >>> outperforming Hibernate. >>> >>> Performance Summary (with respect to Postgres) >>> EclipseLink - 10.5 >>> Hibernate - 9.1 >>> OpenJPA - 6.5 >>> DataNucleus - 6.0 >>> >>> *Issues with OpenJPA.* >>> 1. Spring dropped support back in 2017 and requests to resume support >>> was declined earlier this year >>> https://github.com/spring-projects/spring-framework/issues/20584. There >>> is no guarantee when it will be back in newer versions of Spring. Spring 5 >>> for instance no longer includes the OpenJpaVendorAdaptor. Therefore, future >>> upgrade of Fineract CN will become an issue. >>> >>> 2. OpenJPA has been lagging behind - the stable version for spring >>> supports up to JDK 1.6 (although v3.0.0+ is working to resolve this issue). >>> >>> 3. Bugs and compatibility issues with other libraries. I have first-hand >>> experience with it and it's not pleasant. >>> >>> *Why not DataNucleus?* >>> It is not supported in Spring 4.x and its implementation will require us >>> to completely heavily refactor the JPA Layer in Fineract CN on top of that, >>> it's the slowest. >>> >>> Looking forward to your recommendations and your own evaluations. >>> -- >>> >>> *Regards* >>> >>
