You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Ebenezer Graham <eb...@gmail.com> on 2019/07/01 04:08:44 UTC
[ Discussion ] ORM Migration
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*
Re: [ Discussion ] ORM Migration
Posted by Michael Vorburger <mi...@vorburger.ch>.
Oh and one more thing, re. "3. Bugs and compatibility issues with other
libraries. I have first-hand experience with it and it's not pleasant." I
suspect that https://github.com/apache/fineract/pull/607 may help with
(some of?) those kinds of problems? It was a mistake to initially, when
Mifos X 0> Fineract switched from Hibernate to OpenJPA during the move to
the ASF use the openjpa-all "shaded fat JAR" - but that's relatively easy
to fix, with https://github.com/apache/fineract/pull/607.
On Wed, Jul 10, 2019 at 12:14 AM Michael Vorburger <mi...@vorburger.ch>
wrote:
> Folks,
>
> I'm not entirely convinced yet that we have strong enough reasons to
> justify the effort switching from OpenJPA to e.g. EclipseLink.
>
> Glancing over
> https://github.com/spring-projects/spring-framework/issues/20584, I'm
> unclear if it concludes that Spring Framework actually formally completely
> dropped support for OpenJPA, or if with OpenJPA 3.0.0 they refrained?
> There's also a discussion about "Spring core" vs "shipping
> OpenJpaVendorAdapter with OpenJPA 3.0 itself", and
> https://github.com/spring-projects/spring-framework/issues/18997 says,
> quote: "OpenJPA 3.0 should work fine with standard JPA 2.1 integration in
> Spring, i.e. simply without a JpaVendorAdapter, just like DataNucleus does
> as well (which we never shipped an adapter for). If anything does not work
> out of the box there, please raise it in a separate ticket; we'll sort it
> out ASAP." and "Everything seems to work,"
>
> Has someone actually tested and hit any specific real problems with
> OpenJPA and current Spring versions?
>
> FYI via https://github.com/apache/fineract/pull/608 I seem to be able to
> run OpenJPA even on Java 11 (ASM upgraded).
>
> Best,
> M.
>
> PS: Just for "full disclosure" - I was one of the very first users of
> OpenJPA back when it was SolarMetric Kodo JDO - anyone here old enough to
> remember those days? ;-) Many moons ago I contributed
> https://openjpa.apache.org/openjpaeclipseenhancementbuilder.html. Also
> FYI http://www.vorburger.ch/corejdo/ or
> http://blog1.vorburger.ch/2008/08/testing-openjpa-sql-statements-using.html
> - oh the good ol' days.
>
>
> On Tue, Jul 9, 2019 at 12:24 PM Marta Jankovics <ma...@dpc.hu>
> wrote:
>
>> Hi All,
>>
>> I have experience with Hibernate, EclipseLink and OpenJPA. Hibernate is
>> not an option, as you wrote in the chain below, although it is the default
>> JPA implementation.
>>
>> Comparing EclipseLink and OpenJPA I vote for EclipseLink because of its
>> better performance, transaction handling and no computability issues.
>>
>> I read some articles now about DataNucleus and as a conclusion I would
>> exclude it:
>>
>> https://s3-eu-west-1.amazonaws.com/presentations2012/50_presentation.pdf
>> (2012))
>>
>>
>> https://www.researchgate.net/publication/313263324_Review_on_ORM_based_JPA_implementations
>> (2016)
>>
>>
>> https://pdfs.semanticscholar.org/5db6/f9d267a361debc5ddf7daf61cce82d7cdd5d.pdf
>> (2017)
>>
>> "Very smart policies for collections."
>>
>> "However, in terms of performance prospect DataNucleus is a dominant JPA
>> implementation but due to the *high complexity* and *lack of audience*,
>> it is *not a preferred API*. Another notable problem with DataNucleus
>> was the *lack** of* proper *documentation* support."
>>
>> "With DataNucleus JPA we observed a significant, and unexpected, *degradation
>> of performance* and outofmemory exceptions, particularly with heavy
>> workloads.
>> *Memory leaks* with DataNucleusJPA"
>>
>> Thanks,
>>
>> Márti
>> On 2019. 07. 05. 18:10, Ed Cable wrote:
>>
>> [To: Marta] Are you able to add your thoughts on this discussion?
>>
>> Ed
>>
>>
> On Mon, Jul 1, 2019 at 8:48 AM Awasum Yannick <aw...@apache.org> 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 <aa...@gmail.com> 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 (<eb...@gmail.com>) 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*
>>>>
>>>
Re: [ Discussion ] ORM Migration
Posted by Ebenezer Graham <eg...@alustudent.com>.
Hi Devs,
*Glancing over
> https://github.com/spring-projects/spring-framework/issues/20584
> <https://github.com/spring-projects/spring-framework/issues/20584>, I'm
> unclear if it concludes that Spring Framework actually formally completely
> dropped support for OpenJPA, or if with OpenJPA 3.0.0 they refrained?*
With Regards to support in Spring, I reached out to *Juergen Hoeller* and
he confirmed that they do not intend to bring back OpenJPA support into
Spring Framework itself or into Spring Boot.
This is because *they expect OpenJPA to ship an OpenJpaVendorAdapter for
Spring support *beyond standard JPA. Spring has now limited itself to
providing out-of-the-box support for provider-specific features to
Hibernate and EclipseLink. Moreover, this is the trend major projects are
taking. eg: IBM's WebSphere Liberty and RedHat's WebSphere both dropped
support for OpenJPA.
Spring dropping support is "not entirely a big deal" but coupled with the
minor issues sums up to something significant.
In my opinion, with a number of projects focusing more on Hibernate and
EclipseLink, the latter will become more mainstream hence both will benefit
from the ripple effect of being part of the "mainstream libraries" (eg:
more audience, more books/tutorials will cover both, better Stackoverflow
and search engine results, familiarity with new developers in the long run
etc). For example, Baeldung now has a tutorial (written in Nov 2018)
explaining
EclipseLink integration with Spring and a sample project on Github
https://www.baeldung.com/spring-eclipselink. In contrast, OpenJPA and the
others have none. Eventually, EclipseLink will gain the same stability and
audience as Hibernate whiles the others lag
I will share my experience on some of the issues I encountered when I
started Migrating to OpenJPA. The initial issue was with the build time
enhancement back in May ( details in this thread
https://lists.apache.org/thread.html/88d61ac6f7aee55aeae85bd995b73c94fb0f8dc684fac027e30c814e@%3Cdev.fineract.apache.or
g%3E),
During my search for a solution on the OpenJPA dev list , Francesco, a PMC
member at both OpenJPA and Apache Syncope, gave support and explained how
they are using OpenJPA in the Syncope more on this here.
https://lists.apache.org/thread.html/dc8be4a8bf62a4d044cea759395a0aa406e4e9cf52ac5d4cdd016bde@%3Cdev.openjpa.apache.org%3E
.
For some reason, Syncope uses H2 as the database during enhancement
https://github.com/apache/syncope/blob/2_1_X/core/persistence-jpa/pom.xml#L143-L174
. The fact is OpenJPA is very efficient and works well when paired with H2
and so it makes sense for Syncope's to use it in their context. I don't
know how things pan out when paired with other databases in
production. EclipseLink,
on the other hand, outperforms OpenJPA and even Hibernate when paired with
PostgreSQL with no know issues unlike OpenJPA-PostgreSQL (
http://www.jpab.org/OpenJPA/PostgreSQL/server.html). Even better, we have
some level of guarantee that we will get a similar JPA performance in both
development and production. Hence, my affinity with EclipseLink
Again, compatibility issues only occurred with OpenJPA 2.4 (all issues get
resolved when working with v3.1.0 when I tried it). The issue I noticed
involved the annotation processor and SLF4J shipped with openjpa. Whenever
I integrated v2.4 into spring boot 1.4 and Spring 4.3, SLF4J in OpenJPA
interfered with its counterpart in the microservices - introducing a Marker
parameter in certain statements. Excluding the logger from OpenJPA affected
the Logging channels in OpenJPA) and vice versa. This made it difficult to
debug eventually resulting in a lot of commented out log statements as a
workaround. Sticking with OpenJPA 2.4 will require a proper solution.
Another problem is that Syncope uses a maven plugin which simplifies their
enhancement process. During my test with OpenJPA 3.1.0, I had to provide a
third party plugin to perform entity class enhancements I started with this
https://github.com/schmutterer/gradle-openjpa. However, this introduced an
interesting behaviour where entities will be picked up in certain builds
but return null another time. Full disclosure, I didn't put a lot of effort
in finding the cause or a possible solution given that I had already
started testing out EclipseLink as at that time. During these tests, it was
difficult to debug and trust in the results given that I was combining
libraries which haven't undergone integration tests. The last thing we want
is a JPA Layer which plays hide and seek during production.
In another attempt, I temporarily upgraded the Gradle version to try
https://github.com/radcortez/openjpa-gradle-plugin but dropped it given
that we would have to upgrade Fineract CN's Gradle version just to use
this.
Talking from experience, we can make OpenJPA work in Fineract CN but is it
worth the effort and possible risks (
http://www.jpab.org/OpenJPA/PostgreSQL/server.html couldn't find out if
these issues have been resolved). However, given that its counterpart is
already enjoying out-of-box support plus better efficiency on top of that...
looks like a good option.
I already have a working configuration with EclipseLink here
https://github.com/ebenezergraham/fineract-cn-postgresql/blob/FINCN-2/src/main/java/org/apache/fineract/cn/postgresql/config/EclipseLinkJpaConfiguration.java
https://github.com/ebenezergraham/fineract-cn-postgresql/blob/FINCN-2/build.gradle
and currently wrapping up work on the Minimal Services. More on this in
another thread.
*FYI I recently looked into this kind of topic
> in https://issues.apache.org/jira/browse/LEGAL-462
> <https://issues.apache.org/jira/browse/LEGAL-462>, which you may find
> interesting to glance at in this context. There are, numerous, similar
> other JIRA issues if you search for "LGPL"
> on https://issues.apache.org/jira <https://issues.apache.org/jira>.*
I just looked at the discussions around whitelisting LGPL. It looks
interesting but it has been around for almost a decade now, Aside from the
back and forth on this topic, I doubt it will be resolved anytime soon
given the number of times issues raised on this topic has petered. All the
same, we can't wait for this we need a compliant ORM ASAP
Cheer
On Wed, 10 Jul 2019 at 02:14, Michael Vorburger <mi...@vorburger.ch> wrote:
>
> Folks,
>
> I'm not entirely convinced yet that we have strong enough reasons to
justify the effort switching from OpenJPA to e.g. EclipseLink.
>
> Glancing over
https://github.com/spring-projects/spring-framework/issues/20584, I'm
unclear if it concludes that Spring Framework actually formally completely
dropped support for OpenJPA, or if with OpenJPA 3.0.0 they refrained?
There's also a discussion about "Spring core" vs "shipping
OpenJpaVendorAdapter with OpenJPA 3.0 itself", and
https://github.com/spring-projects/spring-framework/issues/18997 says,
quote: "OpenJPA 3.0 should work fine with standard JPA 2.1 integration in
Spring, i.e. simply without a JpaVendorAdapter, just like DataNucleus does
as well (which we never shipped an adapter for). If anything does not work
out of the box there, please raise it in a separate ticket; we'll sort it
out ASAP." and "Everything seems to work,"
>
> Has someone actually tested and hit any specific real problems with
OpenJPA and current Spring versions?
>
> FYI via https://github.com/apache/fineract/pull/608 I seem to be able to
run OpenJPA even on Java 11 (ASM upgraded).
>
> Best,
> M.
>
> PS: Just for "full disclosure" - I was one of the very first users of
OpenJPA back when it was SolarMetric Kodo JDO - anyone here old enough to
remember those days? ;-) Many moons ago I contributed
https://openjpa.apache.org/openjpaeclipseenhancementbuilder.html. Also FYI
http://www.vorburger.ch/corejdo/ or
http://blog1.vorburger.ch/2008/08/testing-openjpa-sql-statements-using.html
- oh the good ol' days.
>
>
> On Tue, Jul 9, 2019 at 12:24 PM Marta Jankovics <ma...@dpc.hu>
wrote:
>>
>> Hi All,
>>
>> I have experience with Hibernate, EclipseLink and OpenJPA. Hibernate is
not an option, as you wrote in the chain below, although it is the default
JPA implementation.
>>
>> Comparing EclipseLink and OpenJPA I vote for EclipseLink because of its
better performance, transaction handling and no computability issues.
>>
>> I read some articles now about DataNucleus and as a conclusion I would
exclude it:
>>
>> https://s3-eu-west-1.amazonaws.com/presentations2012/50_presentation.pdf
(2012))
>>
>>
https://www.researchgate.net/publication/313263324_Review_on_ORM_based_JPA_implementations
(2016)
>>
>>
https://pdfs.semanticscholar.org/5db6/f9d267a361debc5ddf7daf61cce82d7cdd5d.pdf
(2017)
>>
>> "Very smart policies for collections."
>>
>> "However, in terms of performance prospect DataNucleus is a dominant JPA
implementation but due to the high complexity and lack of audience, it is
not a preferred API. Another notable problem with DataNucleus was the lack
of proper documentation support."
>>
>> "With DataNucleus JPA we observed a significant, and unexpected,
degradation of performance and outofmemory exceptions, particularly with
heavy workloads.
>> Memory leaks with DataNucleusJPA"
>>
>> Thanks,
>>
>> Márti
>>
>> On 2019. 07. 05. 18:10, Ed Cable wrote:
>>
>> [To: Marta] Are you able to add your thoughts on this discussion?
>>
>> Ed
>
>
> On Mon, Jul 1, 2019 at 8:48 AM Awasum Yannick <aw...@apache.org> 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 <aa...@gmail.com> 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 (<eb...@gmail.com>) 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 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
>
Re: [ Discussion ] ORM Migration
Posted by Michael Vorburger <mi...@vorburger.ch>.
Folks,
I'm not entirely convinced yet that we have strong enough reasons to
justify the effort switching from OpenJPA to e.g. EclipseLink.
Glancing over
https://github.com/spring-projects/spring-framework/issues/20584, I'm
unclear if it concludes that Spring Framework actually formally completely
dropped support for OpenJPA, or if with OpenJPA 3.0.0 they refrained?
There's also a discussion about "Spring core" vs "shipping
OpenJpaVendorAdapter with OpenJPA 3.0 itself", and
https://github.com/spring-projects/spring-framework/issues/18997 says,
quote: "OpenJPA 3.0 should work fine with standard JPA 2.1 integration in
Spring, i.e. simply without a JpaVendorAdapter, just like DataNucleus does
as well (which we never shipped an adapter for). If anything does not work
out of the box there, please raise it in a separate ticket; we'll sort it
out ASAP." and "Everything seems to work,"
Has someone actually tested and hit any specific real problems with OpenJPA
and current Spring versions?
FYI via https://github.com/apache/fineract/pull/608 I seem to be able to
run OpenJPA even on Java 11 (ASM upgraded).
Best,
M.
PS: Just for "full disclosure" - I was one of the very first users of
OpenJPA back when it was SolarMetric Kodo JDO - anyone here old enough to
remember those days? ;-) Many moons ago I contributed
https://openjpa.apache.org/openjpaeclipseenhancementbuilder.html. Also FYI
http://www.vorburger.ch/corejdo/ or
http://blog1.vorburger.ch/2008/08/testing-openjpa-sql-statements-using.html
- oh the good ol' days.
On Tue, Jul 9, 2019 at 12:24 PM Marta Jankovics <ma...@dpc.hu>
wrote:
> Hi All,
>
> I have experience with Hibernate, EclipseLink and OpenJPA. Hibernate is
> not an option, as you wrote in the chain below, although it is the default
> JPA implementation.
>
> Comparing EclipseLink and OpenJPA I vote for EclipseLink because of its
> better performance, transaction handling and no computability issues.
>
> I read some articles now about DataNucleus and as a conclusion I would
> exclude it:
>
> https://s3-eu-west-1.amazonaws.com/presentations2012/50_presentation.pdf
> (2012))
>
>
> https://www.researchgate.net/publication/313263324_Review_on_ORM_based_JPA_implementations
> (2016)
>
>
> https://pdfs.semanticscholar.org/5db6/f9d267a361debc5ddf7daf61cce82d7cdd5d.pdf
> (2017)
>
> "Very smart policies for collections."
>
> "However, in terms of performance prospect DataNucleus is a dominant JPA
> implementation but due to the *high complexity* and *lack of audience*,
> it is *not a preferred API*. Another notable problem with DataNucleus was
> the *lack** of* proper *documentation* support."
>
> "With DataNucleus JPA we observed a significant, and unexpected, *degradation
> of performance* and outofmemory exceptions, particularly with heavy
> workloads.
> *Memory leaks* with DataNucleusJPA"
>
> Thanks,
>
> Márti
> On 2019. 07. 05. 18:10, Ed Cable wrote:
>
> [To: Marta] Are you able to add your thoughts on this discussion?
>
> Ed
>
>
On Mon, Jul 1, 2019 at 8:48 AM Awasum Yannick <aw...@apache.org> 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 <aa...@gmail.com> 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 (<eb...@gmail.com>) 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*
>>>
>>
Re: [ Discussion ] ORM Migration
Posted by Awasum Yannick <aw...@apache.org>.
Hi All,
Apache Syncope had to write a plugin to integrate their solution with
Spring 5.
https://github.com/apache/syncope/commit/17a8eb5d99a84608a64927b00e7d9352d640517e
Looks like the Spring team will support just 2 ORMs officially moving
forward: Hibernate and EclipseLink. Good thing Eclipse link happens to be
compatible with Apache license and also officially supported by future
version of Spring.
On Wed, Jul 10, 2019 at 8:50 AM Michael Vorburger <mi...@vorburger.ch> wrote:
> On Wed, Jul 10, 2019 at 8:43 AM Isaac Kamga <u2...@gmail.com> wrote:
>
>> 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 ?
>>
>
> I doubt it. I think Hibernate is, unfortunately (I do actually agree), a
> non-starter and not a realistic option for Fineract at the ASF.
>
> FYI I recently looked into this kind of topic in
> https://issues.apache.org/jira/browse/LEGAL-462, which you may find
> interesting to glance at in this context. There are, numerous, similar
> other JIRA issues if you search for "LGPL" on
> https://issues.apache.org/jira.
>
>
>> 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 <
>> victor.romero@fintecheando.mx> 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 <aa...@gmail.com> 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 (<eb...@gmail.com>) 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*
>>>>>
>>>>
Re: [ Discussion ] ORM Migration
Posted by Michael Vorburger <mi...@vorburger.ch>.
On Wed, Jul 10, 2019 at 8:43 AM Isaac Kamga <u2...@gmail.com> wrote:
> 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 ?
>
I doubt it. I think Hibernate is, unfortunately (I do actually agree), a
non-starter and not a realistic option for Fineract at the ASF.
FYI I recently looked into this kind of topic in
https://issues.apache.org/jira/browse/LEGAL-462, which you may find
interesting to glance at in this context. There are, numerous, similar
other JIRA issues if you search for "LGPL" on https://issues.apache.org/jira
.
> 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 <
> victor.romero@fintecheando.mx> 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 <aa...@gmail.com> 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 (<eb...@gmail.com>) 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*
>>>>
>>>
Re: [ Discussion ] ORM Migration
Posted by Isaac Kamga <u2...@gmail.com>.
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 <
victor.romero@fintecheando.mx> 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 <aa...@gmail.com> 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 (<eb...@gmail.com>) 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*
>>>
>>
Re: [ Discussion ] ORM Migration
Posted by Victor Manuel Romero Rodriguez <vi...@fintecheando.mx>.
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 <aasaru@gmail.com
> <ma...@gmail.com>> 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 (<ebenezergraham69@gmail.com
> <ma...@gmail.com>>) 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*
>
Re: [ Discussion ] ORM Migration
Posted by Awasum Yannick <aw...@apache.org>.
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 <aa...@gmail.com> 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 (<eb...@gmail.com>) 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*
>>
>
Re: [ Discussion ] ORM Migration
Posted by Juhan Aasaru <aa...@gmail.com>.
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 (<eb...@gmail.com>) 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*
>