|
Eclipselink Vs Hibernate
Hi,
May I request the eclipselink community to enlighten me on certain aspects of eclipselink where I could not find convincing answers when eclipselink is compared with hibernate?
Before I start let me make it very clear that I'm not a hibernate fan and I just want to confirm that eclipselink is not lagging behind in certain areas where hibernate advertises
that it excels; on the other hand I don't want to bring back the infamous ORM wars with this mail :)
To start with, here are the feaures the hibernate website highlights:
3. Enhanced Query Facilities, like the DetachedCriteria and the HQL on top of JPQL 4. Threadsafeness and Non-blocking data access
I know how simplified and powerful Eclipselink native Expression API is (should I tell you how much I loathe the hibernate criteria API? ), but not sure if it can be used when the database session is closed, for example to build the query from UI layer; and I did not find any JPQL enhancements either by eclipselink.
Also, I found in my googling a search library called Compass which is based on Lucene that can be used with eclipselink for searching, but not sure how eclipselinkish ( if i can use the word ) its API is while on the other hand hibernate search is very much integrated with hibernate core.
When it comes to shards, I think eclipselink does not have this as of now (may this be taken as a feature request?).
Please correct me if have presented anything wrongly here; my intention is to get a better picture of where eclipselink stands when compared to hibernate in the above said feature list.
I know hibernate is no match when it comes to the breadth of the variety of datasources that eclipselink supports; but I want to narrow the comparision to where hibernate has some foothold and can
compete with the monster :)
The reason I'm doing this is to fight with my friends who work on hibernate and tell them that theirs is not the whole world and much more lies out side of the confines they have set themselves in.
Thanks and Regards,
Samba
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
I'm not very familiar with these Hibernate extensions, so will do my best to comment on this.
First off, EclipseLink offers many advanced features not in Hibernate:
- Moxy - object-XML mapping and JAXB
- SDO
- DBWS - database webservices
- EIS
- OR data-type mappings
- Caching and cache coordination
- extended Oracle database and JDBC integration
- TopLink Grid uses EclipseLink
Also many new features are being developed in EclipseLink 2.0 as the JPA 2.0 reference implementation, including the criteria API.
1. Hibernate Validator
- From Hibernate's website this seems to be obsolete, or replaced with "JSR 303: Bean Validation". So would seem to have little to do with Hibernate any more, and any such implemention could be used with any persistence product including EclipseLink.
2. Hibernate Search
- I think Lucene also has an EclipseLink integration.
3. Enhanced Query Facilities like the DetachedCriteria and the HQL on top of JPQL
- EclipseLink Expressions are always detached, and can even be serialized.
- EclipseLink is adding many JPQL enhancements as part of JPA 2.0.
4. Threadsafeness and Non-blocking data access
- EclipseLink is always thread-safe and non-blocking, and extensive work is put into ensuring EclipseLink is the most peformant persistence product.
5. Hibernate Shards
- I'm not that familiar with this, but I believe it is similar to EclipseLink's SessionBroker feature.
saasira wrote:
Hi,
May I request the eclipselink community to enlighten me on certain aspects
of eclipselink where I could not find convincing answers when eclipselink is
compared with hibernate?
Before I start let me make it very clear that I'm not a hibernate fan and
I just want to confirm that eclipselink is not lagging behind in certain
areas where hibernate advertises
that it excels; on the other hand I don't want to bring back the infamous
ORM wars with this mail :)
To start with, here are the feaures the hibernate website highlights:
1. *Hibernate Validator* < https://www.hibernate.org/412.html>
2. *Hibernate Search* < https://www.hibernate.org/410.html>
3. Enhanced *Query Facilities* < https://www.hibernate.org/347.html>,
like the DetachedCriteria and the HQL on top of JPQL
4. Threadsafeness and Non-blocking data access
5. Google Contributed *Hibernate
Shards*< https://www.hibernate.org/414.html>
I know how simplified and powerful Eclipselink native Expression API is
(should I tell you how much I loathe the hibernate criteria API? ), but not
sure if it can be used when the database session is closed, for
example to build the query from UI layer; and I did not find any JPQL
enhancements either by eclipselink.
Also, I found in my googling a search library called Compass which is
based on Lucene that can be used with eclipselink for searching, but not
sure how eclipselinkish ( if i can use the word ) its API is while on the
other hand hibernate search is very much integrated with hibernate core.
When it comes to shards, I think eclipselink does not have this as of now
(may this be taken as a feature request?).
Please correct me if have presented anything wrongly here; my intention
is to get a better picture of where eclipselink stands when compared to
hibernate in the above said feature list.
I know hibernate is no match when it comes to the breadth of the variety
of datasources that eclipselink supports; but I want to narrow the
comparision to where hibernate has some foothold and can
compete with the monster :)
The reason I'm doing this is to fight with my friends who work on
hibernate and tell them that theirs is not the whole world and much more
lies out side of the confines they have set themselves in.
Thanks and Regards,
Samba
|
|
Re: Eclipselink Vs Hibernate
James,
Thanks for your response.
Its good to know that Eclipselink Expression API is detached and I just came to know that we can use these expressions with
((JpaEntityManager)entityManager.getDelegate()).createQuery(Expression expression, Class resultType);
method which returns the standard JPA Query object.
Also thanks again for letting me know about JSR-303, the Bean Validation Specification.
In addition to this, I'm interested in knowing a little more about Eclipselink's SessionBroker architecture.
Is this feature exposed through the JPA entity manager API?
Something like persistence xml property extentions to specify the session broker configuration xml file would be very helpful.
It would be great if the JpaEntityManager class makes using the Session Broker transparent of the internal session manager and session broker details.
If doing these are not possible as of now, can these be taken as a feature request?
Thanks and Regards,
Samba
On Thu, Jun 18, 2009 at 1:39 AM, James Sutherland <jamesssss@...> wrote:
I'm not very familiar with these Hibernate extensions, so will do my best to
comment on this.
First off, EclipseLink offers many advanced features not in Hibernate:
- Moxy - object-XML mapping and JAXB
- SDO
- DBWS - database webservices
- EIS
- OR data-type mappings
- Caching and cache coordination
- extended Oracle database and JDBC integration
- TopLink Grid uses EclipseLink
Also many new features are being developed in EclipseLink 2.0 as the JPA 2.0
reference implementation, including the criteria API.
1. Hibernate Validator
- From Hibernate's website this seems to be obsolete, or replaced with "JSR
303: Bean Validation". So would seem to have little to do with Hibernate
any more, and any such implemention could be used with any persistence
product including EclipseLink.
2. Hibernate Search
- I think Lucene also has an EclipseLink integration.
3. Enhanced Query Facilities like the DetachedCriteria and the HQL on top of
JPQL
- EclipseLink Expressions are always detached, and can even be serialized.
- EclipseLink is adding many JPQL enhancements as part of JPA 2.0.
4. Threadsafeness and Non-blocking data access
- EclipseLink is always thread-safe and non-blocking, and extensive work is
put into ensuring EclipseLink is the most peformant persistence product.
5. Hibernate Shards
- I'm not that familiar with this, but I believe it is similar to
EclipseLink's SessionBroker feature.
saasira wrote:
>
> Hi,
>
> May I request the eclipselink community to enlighten me on certain
> aspects
> of eclipselink where I could not find convincing answers when eclipselink
> is
> compared with hibernate?
> Before I start let me make it very clear that I'm not a hibernate fan
> and
> I just want to confirm that eclipselink is not lagging behind in certain
> areas where hibernate advertises
> that it excels; on the other hand I don't want to bring back the
> infamous
> ORM wars with this mail :)
>
> To start with, here are the feaures the hibernate website highlights:
>
> 1. *Hibernate Validator* <https://www.hibernate.org/412.html>
> 2. *Hibernate Search* <https://www.hibernate.org/410.html>
> 3. Enhanced *Query Facilities* <https://www.hibernate.org/347.html>,
> like the DetachedCriteria and the HQL on top of JPQL
> 4. Threadsafeness and Non-blocking data access
> 5. Google Contributed *Hibernate
> Shards*<https://www.hibernate.org/414.html>
>
>
> I know how simplified and powerful Eclipselink native Expression API is
> (should I tell you how much I loathe the hibernate criteria API? ), but
> not
> sure if it can be used when the database session is closed, for
> example to build the query from UI layer; and I did not find any JPQL
> enhancements either by eclipselink.
>
> Also, I found in my googling a search library called Compass which is
> based on Lucene that can be used with eclipselink for searching, but not
> sure how eclipselinkish ( if i can use the word ) its API is while on the
> other hand hibernate search is very much integrated with hibernate core.
>
> When it comes to shards, I think eclipselink does not have this as of
> now
> (may this be taken as a feature request?).
>
> Please correct me if have presented anything wrongly here; my intention
> is to get a better picture of where eclipselink stands when compared to
> hibernate in the above said feature list.
>
> I know hibernate is no match when it comes to the breadth of the variety
> of datasources that eclipselink supports; but I want to narrow the
> comparision to where hibernate has some foothold and can
> compete with the monster :)
>
> The reason I'm doing this is to fight with my friends who work on
> hibernate and tell them that theirs is not the whole world and much more
> lies out side of the confines they have set themselves in.
>
> Thanks and Regards,
> Samba
>
>
-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://www.nabble.com/Eclipselink-Vs-Hibernate-tp24041213p24081107.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
RE: Eclipselink Vs Hibernate
Samba,
At JavaOne (CommunityOne) I presented and EclipseLink talk focussed on our JPA 2.0 support. I highlighted the following example of using our expression/query API.
> JP QL:
SELECT e FROM Employee e WHERE e.name LIKE ‘D%’
> EclipseLink Expressions:
ExpressionBuilder eb = new ExpressionBuilder();
ReadAllQuery q = new ReadAllQuery(Employee.class, eb);
q.setSelectionCriteria(eb.get(“name”).like(“D%”));
List<Employee> results = JpaHelper.createQuery(em, q).getResultList();
> JPA 2.0 Criteria:
QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery q = qb.create();
Root emp = q.from(Employee.class);
q.select(emp);
q.where(qb.like(emp.get(“name”), “D%”));
List<Employee> results = em.createQuery(q).getResultList();
I just wanted to show how the JPA 2.0 criteria API aligns with our existing expression/query framework and how the JpaHelper class can be used.
Doug
-----Original Message-----
From: Samba [mailto: saasira@...]
Sent: Thursday, June 18, 2009 2:30 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] Eclipselink Vs Hibernate
James,
Thanks for your response.
Its good to know that Eclipselink Expression API is detached and I just came to know that we can use these expressions with
((JpaEntityManager)entityManager.getDelegate()).createQuery(Expression expression, Class resultType);
method which returns the standard JPA Query object.
Also thanks again for letting me know about JSR-303, the Bean Validation Specification.
In addition to this, I'm interested in knowing a little more about Eclipselink's SessionBroker architecture.
Is this feature exposed through the JPA entity manager API?
Something like persistence xml property extentions to specify the session broker configuration xml file would be very helpful.
It would be great if the JpaEntityManager class makes using the Session Broker transparent of the internal session manager and session broker details.
If doing these are not possible as of now, can these be taken as a feature request?
Thanks and Regards,
Samba
On Thu, Jun 18, 2009 at 1:39 AM, James Sutherland < jamesssss@...> wrote:
I'm not very familiar with these Hibernate extensions, so will do my best to
comment on this.
First off, EclipseLink offers many advanced features not in Hibernate:
- Moxy - object-XML mapping and JAXB
- SDO
- DBWS - database webservices
- EIS
- OR data-type mappings
- Caching and cache coordination
- extended Oracle database and JDBC integration
- TopLink Grid uses EclipseLink
Also many new features are being developed in EclipseLink 2.0 as the JPA 2.0
reference implementation, including the criteria API.
1. Hibernate Validator
- From Hibernate's website this seems to be obsolete, or replaced with "JSR
303: Bean Validation". So would seem to have little to do with Hibernate
any more, and any such implemention could be used with any persistence
product including EclipseLink.
2. Hibernate Search
- I think Lucene also has an EclipseLink integration.
3. Enhanced Query Facilities like the DetachedCriteria and the HQL on top of
JPQL
- EclipseLink Expressions are always detached, and can even be serialized.
- EclipseLink is adding many JPQL enhancements as part of JPA 2.0.
4. Threadsafeness and Non-blocking data access
- EclipseLink is always thread-safe and non-blocking, and extensive work is
put into ensuring EclipseLink is the most peformant persistence product.
5. Hibernate Shards
- I'm not that familiar with this, but I believe it is similar to
EclipseLink's SessionBroker feature.
saasira wrote:
>
> Hi,
>
> May I request the eclipselink community to enlighten me on certain
> aspects
> of eclipselink where I could not find convincing answers when eclipselink
> is
> compared with hibernate?
> Before I start let me make it very clear that I'm not a hibernate fan
> and
> I just want to confirm that eclipselink is not lagging behind in certain
> areas where hibernate advertises
> that it excels; on the other hand I don't want to bring back the
> infamous
> ORM wars with this mail :)
>
> To start with, here are the feaures the hibernate website highlights:
>
> 1. *Hibernate Validator* < https://www.hibernate.org/412.html>
> 2. *Hibernate Search* < https://www.hibernate.org/410.html>
> 3. Enhanced *Query Facilities* < https://www.hibernate.org/347.html>,
> like the DetachedCriteria and the HQL on top of JPQL
> 4. Threadsafeness and Non-blocking data access
> 5. Google Contributed *Hibernate
> Shards*< https://www.hibernate.org/414.html>
>
>
> I know how simplified and powerful Eclipselink native Expression API is
> (should I tell you how much I loathe the hibernate criteria API? ), but
> not
> sure if it can be used when the database session is closed, for
> example to build the query from UI layer; and I did not find any JPQL
> enhancements either by eclipselink.
>
> Also, I found in my googling a search library called Compass which is
> based on Lucene that can be used with eclipselink for searching, but not
> sure how eclipselinkish ( if i can use the word ) its API is while on the
> other hand hibernate search is very much integrated with hibernate core.
>
> When it comes to shards, I think eclipselink does not have this as of
> now
> (may this be taken as a feature request?).
>
> Please correct me if have presented anything wrongly here; my intention
> is to get a better picture of where eclipselink stands when compared to
> hibernate in the above said feature list.
>
> I know hibernate is no match when it comes to the breadth of the variety
> of datasources that eclipselink supports; but I want to narrow the
> comparision to where hibernate has some foothold and can
> compete with the monster :)
>
> The reason I'm doing this is to fight with my friends who work on
> hibernate and tell them that theirs is not the whole world and much more
> lies out side of the confines they have set themselves in.
>
> Thanks and Regards,
> Samba
>
>
-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/ EclipseLink , http://www.oracle.com/technology/products/ias/toplink/TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://www.nabble.com/Eclipselink-Vs-Hibernate-tp24041213p24081107.htmlSent from the EclipseLink - Users mailing list archive at Nabble.com.
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
James,
Thanks for sharing this info; I feel Eclipselink Expression API is more intuitive than JPA Criteia API  ;
I'm actually trying to compare and contrast the Session Broker architecture in EclipseLink and the Hibernate Shards;
and observed a major difference between the two.
Here is a summary of what Session Broker is not:
Session Broker Session Limitations
Although the session broker is a powerful tool that lets you use data that is distributed across multiple databases from a single application, it has some limitations:
-
You cannot split multiple table descriptors across databases.
-
Each class must reside on only one database.
-
You cannot use joins through expressions across databases.
-
Many-to-many join tables must reside on the same database as the target object (See "Many-to-Many Join Tables and Direct Collection Tables" for a work-around for this limitation).
Here is what Hibernate Shards is:.
Hibernate Shards addresses the problem of Horizontal parititioning by facilitating a single view ( Java Class ) of the data that may reside across several database servers which essentially means all mapped schema would be identical across all the servers, and Hibernate Shards provides a way to the developers to store different set of records(rows) on different database servers based on predefined/user-extended algorithm. So, in hibernate shards, most probably Each class will reside on every database.
I believe EclipseLink has the infrastructure to handle these kind of use cases but it needs a little dressing up of the existing Session Broker architecture.
Sorry for repeating my earlier question, Can I log feature request asking for eclipselink to support Horizontal Partitioning ( Others may suggest Vertical Partitioning as well)? These advanced database design/maintenence strategies are very much essential for the birth of sites like twitter, linkedin, facebook, etc in Java.
Regards,
Samba
On Fri, Jun 19, 2009 at 12:52 AM, Douglas Clarke <DOUGLAS.CLARKE@...> wrote:
Samba,
At JavaOne (CommunityOne) I presented and EclipseLink talk focussed on our JPA 2.0 support. I highlighted the following example of using our expression/query API.
> JP QL:
SELECT e FROM Employee e WHERE e.name LIKE ‘D%’
> EclipseLink Expressions:
ExpressionBuilder eb = new ExpressionBuilder();
ReadAllQuery q = new ReadAllQuery(Employee.class, eb);
q.setSelectionCriteria(eb.get(“name”).like(“D%”));
List<Employee> results = JpaHelper.createQuery(em, q).getResultList();
> JPA 2.0 Criteria:
QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery q = qb.create();
Root emp = q.from(Employee.class);
q.select(emp);
q.where(qb.like(emp.get(“name”), “D%”));
List<Employee> results = em.createQuery(q).getResultList();
I just wanted to show how the JPA 2.0 criteria API aligns with our existing expression/query framework and how the JpaHelper class can be used.
Doug
-----Original Message----- From: Samba [mailto: saasira@...] Sent: Thursday, June 18, 2009 2:30 PM To: EclipseLink User Discussions Subject: Re: [eclipselink-users] Eclipselink Vs Hibernate
James, Thanks for your response. Its good to know that Eclipselink Expression API is detached and I just came to know that we can use these expressions with ((JpaEntityManager)entityManager.getDelegate()).createQuery(Expression expression, Class resultType);
method which returns the standard JPA Query object. Also thanks again for letting me know about JSR-303, the Bean Validation Specification. In addition to this, I'm interested in knowing a little more about Eclipselink's SessionBroker architecture.
Is this feature exposed through the JPA entity manager API? Something like persistence xml property extentions to specify the session broker configuration xml file would be very helpful. It would be great if the JpaEntityManager class makes using the Session Broker transparent of the internal session manager and session broker details.
If doing these are not possible as of now, can these be taken as a feature request? Thanks and Regards, Samba On Thu, Jun 18, 2009 at 1:39 AM, James Sutherland < jamesssss@...> wrote:
I'm not very familiar with these Hibernate extensions, so will do my best to comment on this. First off, EclipseLink offers many advanced features not in Hibernate: - Moxy - object-XML mapping and JAXB
- SDO - DBWS - database webservices - EIS - OR data-type mappings - Caching and cache coordination - extended Oracle database and JDBC integration - TopLink Grid uses EclipseLink Also many new features are being developed in EclipseLink 2.0 as the JPA 2.0
reference implementation, including the criteria API. 1. Hibernate Validator - From Hibernate's website this seems to be obsolete, or replaced with "JSR 303: Bean Validation". So would seem to have little to do with Hibernate
any more, and any such implemention could be used with any persistence product including EclipseLink. 2. Hibernate Search - I think Lucene also has an EclipseLink integration. 3. Enhanced Query Facilities like the DetachedCriteria and the HQL on top of
JPQL - EclipseLink Expressions are always detached, and can even be serialized. - EclipseLink is adding many JPQL enhancements as part of JPA 2.0. 4. Threadsafeness and Non-blocking data access
- EclipseLink is always thread-safe and non-blocking, and extensive work is put into ensuring EclipseLink is the most peformant persistence product. 5. Hibernate Shards - I'm not that familiar with this, but I believe it is similar to
EclipseLink's SessionBroker feature. saasira wrote: > > Hi, > > May I request the eclipselink community to enlighten me on certain > aspects > of eclipselink where I could not find convincing answers when eclipselink
> is > compared with hibernate? > Before I start let me make it very clear that I'm not a hibernate fan > and > I just want to confirm that eclipselink is not lagging behind in certain
> areas where hibernate advertises > that it excels; on the other hand I don't want to bring back the > infamous > ORM wars with this mail :) > > To start with, here are the feaures the hibernate website highlights:
> > 1. *Hibernate Validator* < https://www.hibernate.org/412.html> > 2. *Hibernate Search* < https://www.hibernate.org/410.html>
> 3. Enhanced *Query Facilities* < https://www.hibernate.org/347.html>, > like the DetachedCriteria and the HQL on top of JPQL > 4. Threadsafeness and Non-blocking data access
> 5. Google Contributed *Hibernate > Shards*< https://www.hibernate.org/414.html> > > > I know how simplified and powerful Eclipselink native Expression API is
> (should I tell you how much I loathe the hibernate criteria API? ), but > not > sure if it can be used when the database session is closed, for > example to build the query from UI layer; and I did not find any JPQL
> enhancements either by eclipselink. > > Also, I found in my googling a search library called Compass which is > based on Lucene that can be used with eclipselink for searching, but not > sure how eclipselinkish ( if i can use the word ) its API is while on the
> other hand hibernate search is very much integrated with hibernate core. > > When it comes to shards, I think eclipselink does not have this as of > now > (may this be taken as a feature request?).
> > Please correct me if have presented anything wrongly here; my intention > is to get a better picture of where eclipselink stands when compared to > hibernate in the above said feature list.
> > I know hibernate is no match when it comes to the breadth of the variety > of datasources that eclipselink supports; but I want to narrow the > comparision to where hibernate has some foothold and can
> compete with the monster :) > > The reason I'm doing this is to fight with my friends who work on > hibernate and tell them that theirs is not the whole world and much more > lies out side of the confines they have set themselves in.
> > Thanks and Regards, > Samba > > ----- http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/ EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink , http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence -- View this message in context: http://www.nabble.com/Eclipselink-Vs-Hibernate-tp24041213p24081107.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com. _______________________________________________ eclipselink-users mailing list eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users_______________________________________________ eclipselink-users mailing list
eclipselink-users@...https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
Sorry Doug, I did not notice that it is you who replied;
Thanks for sharing the info....
Regards,
Samba
On Fri, Jun 19, 2009 at 2:43 AM, Samba <saasira@...> wrote:
James,
Thanks for sharing this info; I feel Eclipselink Expression API is more intuitive than JPA Criteia API  ;
I'm actually trying to compare and contrast the Session Broker architecture in EclipseLink and the Hibernate Shards;
and observed a major difference between the two.
Here is a summary of what Session Broker is not:
Session Broker Session Limitations
Although the session broker is a powerful tool that lets you use data that is distributed across multiple databases from a single application, it has some limitations:
-
You cannot split multiple table descriptors across databases.
-
Each class must reside on only one database.
-
You cannot use joins through expressions across databases.
-
Many-to-many join tables must reside on the same database as the target object (See "Many-to-Many Join Tables and Direct Collection Tables" for a work-around for this limitation).
Here is what Hibernate Shards is:.
Hibernate Shards addresses the problem of Horizontal parititioning by facilitating a single view ( Java Class ) of the data that may reside across several database servers which essentially means all mapped schema would be identical across all the servers, and Hibernate Shards provides a way to the developers to store different set of records(rows) on different database servers based on predefined/user-extended algorithm. So, in hibernate shards, most probably Each class will reside on every database.
I believe EclipseLink has the infrastructure to handle these kind of use cases but it needs a little dressing up of the existing Session Broker architecture.
Sorry for repeating my earlier question, Can I log feature request asking for eclipselink to support Horizontal Partitioning ( Others may suggest Vertical Partitioning as well)? These advanced database design/maintenence strategies are very much essential for the birth of sites like twitter, linkedin, facebook, etc in Java.
Regards,
Samba
On Fri, Jun 19, 2009 at 12:52 AM, Douglas Clarke <DOUGLAS.CLARKE@...> wrote:
Samba,
At JavaOne (CommunityOne) I presented and EclipseLink talk focussed on our JPA 2.0 support. I highlighted the following example of using our expression/query API.
> JP QL:
SELECT e FROM Employee e WHERE e.name LIKE ‘D%’
> EclipseLink Expressions:
ExpressionBuilder eb = new ExpressionBuilder();
ReadAllQuery q = new ReadAllQuery(Employee.class, eb);
q.setSelectionCriteria(eb.get(“name”).like(“D%”));
List<Employee> results = JpaHelper.createQuery(em, q).getResultList();
> JPA 2.0 Criteria:
QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery q = qb.create();
Root emp = q.from(Employee.class);
q.select(emp);
q.where(qb.like(emp.get(“name”), “D%”));
List<Employee> results = em.createQuery(q).getResultList();
I just wanted to show how the JPA 2.0 criteria API aligns with our existing expression/query framework and how the JpaHelper class can be used.
Doug
-----Original Message----- From: Samba [mailto: saasira@...] Sent: Thursday, June 18, 2009 2:30 PM To: EclipseLink User Discussions Subject: Re: [eclipselink-users] Eclipselink Vs Hibernate
James, Thanks for your response. Its good to know that Eclipselink Expression API is detached and I just came to know that we can use these expressions with ((JpaEntityManager)entityManager.getDelegate()).createQuery(Expression expression, Class resultType);
method which returns the standard JPA Query object. Also thanks again for letting me know about JSR-303, the Bean Validation Specification. In addition to this, I'm interested in knowing a little more about Eclipselink's SessionBroker architecture.
Is this feature exposed through the JPA entity manager API? Something like persistence xml property extentions to specify the session broker configuration xml file would be very helpful. It would be great if the JpaEntityManager class makes using the Session Broker transparent of the internal session manager and session broker details.
If doing these are not possible as of now, can these be taken as a feature request? Thanks and Regards, Samba On Thu, Jun 18, 2009 at 1:39 AM, James Sutherland < jamesssss@...> wrote:
I'm not very familiar with these Hibernate extensions, so will do my best to comment on this. First off, EclipseLink offers many advanced features not in Hibernate: - Moxy - object-XML mapping and JAXB
- SDO - DBWS - database webservices - EIS - OR data-type mappings - Caching and cache coordination - extended Oracle database and JDBC integration - TopLink Grid uses EclipseLink Also many new features are being developed in EclipseLink 2.0 as the JPA 2.0
reference implementation, including the criteria API. 1. Hibernate Validator - From Hibernate's website this seems to be obsolete, or replaced with "JSR 303: Bean Validation". So would seem to have little to do with Hibernate
any more, and any such implemention could be used with any persistence product including EclipseLink. 2. Hibernate Search - I think Lucene also has an EclipseLink integration. 3. Enhanced Query Facilities like the DetachedCriteria and the HQL on top of
JPQL - EclipseLink Expressions are always detached, and can even be serialized. - EclipseLink is adding many JPQL enhancements as part of JPA 2.0. 4. Threadsafeness and Non-blocking data access
- EclipseLink is always thread-safe and non-blocking, and extensive work is put into ensuring EclipseLink is the most peformant persistence product. 5. Hibernate Shards - I'm not that familiar with this, but I believe it is similar to
EclipseLink's SessionBroker feature. saasira wrote: > > Hi, > > May I request the eclipselink community to enlighten me on certain > aspects > of eclipselink where I could not find convincing answers when eclipselink
> is > compared with hibernate? > Before I start let me make it very clear that I'm not a hibernate fan > and > I just want to confirm that eclipselink is not lagging behind in certain
> areas where hibernate advertises > that it excels; on the other hand I don't want to bring back the > infamous > ORM wars with this mail :) > > To start with, here are the feaures the hibernate website highlights:
> > 1. *Hibernate Validator* < https://www.hibernate.org/412.html> > 2. *Hibernate Search* < https://www.hibernate.org/410.html>
> 3. Enhanced *Query Facilities* < https://www.hibernate.org/347.html>, > like the DetachedCriteria and the HQL on top of JPQL > 4. Threadsafeness and Non-blocking data access
> 5. Google Contributed *Hibernate > Shards*< https://www.hibernate.org/414.html> > > > I know how simplified and powerful Eclipselink native Expression API is
> (should I tell you how much I loathe the hibernate criteria API? ), but > not > sure if it can be used when the database session is closed, for > example to build the query from UI layer; and I did not find any JPQL
> enhancements either by eclipselink. > > Also, I found in my googling a search library called Compass which is > based on Lucene that can be used with eclipselink for searching, but not > sure how eclipselinkish ( if i can use the word ) its API is while on the
> other hand hibernate search is very much integrated with hibernate core. > > When it comes to shards, I think eclipselink does not have this as of > now > (may this be taken as a feature request?).
> > Please correct me if have presented anything wrongly here; my intention > is to get a better picture of where eclipselink stands when compared to > hibernate in the above said feature list.
> > I know hibernate is no match when it comes to the breadth of the variety > of datasources that eclipselink supports; but I want to narrow the > comparision to where hibernate has some foothold and can
> compete with the monster :) > > The reason I'm doing this is to fight with my friends who work on > hibernate and tell them that theirs is not the whole world and much more > lies out side of the confines they have set themselves in.
> > Thanks and Regards, > Samba > > ----- http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/ EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink , http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence -- View this message in context: http://www.nabble.com/Eclipselink-Vs-Hibernate-tp24041213p24081107.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com. _______________________________________________ eclipselink-users mailing list eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users_______________________________________________ eclipselink-users mailing list
eclipselink-users@...https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
RE: Eclipselink Vs Hibernate
Some parts of this message have been removed.
Learn more about Nabble's security policy.
SessionBroker is not supported with JPA API, it is a dropped
functionality from the old native TopLink API: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260258
The implementation on the old native TopLink API just started to
be usable, it had lot of bugs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=241681
& https://bugs.eclipse.org/bugs/show_bug.cgi?id=269213
I have just finished to re-code SessionBroker for our client to
get something JPA compatible. I will submit it to the community in the
next couple of weeks. I tried to get a neutral layer, so could be used easily with
any JPA implementation like Hibernate.
EclipseLink is used to have problem with locking, latest are: http://forums.oracle.com/forums/thread.jspa?forumID=48&threadID=909860
& https://bugs.eclipse.org/bugs/show_bug.cgi?id=275046
There is a tendency in the development team to cut corner on
correctness and thread safety for better performance. So by default Calendar,
which is not thread safe itself, is handled by EclipseLink like it is immutable
and thread safe by default. Calendar is not thread safe even if never mutated. https://bugs.eclipse.org/bugs/show_bug.cgi?id=252047
One of the problem I’m having with EclipseLink Expressions
is that when you do a join on unmapped relationship using dynamic code, if you
introduce two new ExpressionBuilder(classX) on the same class, you will get 2
times the same table in the from clause so Cartesian product. I’m not
sure if a more elegant solution could be available and how Hibernate handle
this.
EclipseLink JMS invalidation is not J2EE compliant and also not JMS
compliant, so on some server like WebSphere, threads are hanging: http://forums.oracle.com/forums/thread.jspa?messageID=3407365
Compared to Hibernate, EclipseLink has no real support to
plug-ins other second level cache, they are trying but not really usable at
this point. The problem is by design. EclipseLink keeps complete object with
their references in the second level cache, where Hibernate doesn’t. So
with Hibernate it’s lot more natural to be able to support other cache
provider. I heard some Oracle people find Hibernate approach silly, but in
reality many of the locking, not thread safe, and other problem with EclipseLink
can be link to the design keeping complete object in the second level cache.
EclipseLink code is not so easy to reuse/extend, probably
because less users are stretching flexibility. https://bugs.eclipse.org/bugs/show_bug.cgi?id=279895
& https://bugs.eclipse.org/bugs/show_bug.cgi?id=274417
There is no doubt that a product used lot more than another will
be more tested, be more flexible and have more third parties supporting it.
What is exclusive to EclipseLink is query in memory. However, in
general it’s not leveraged. For example, what is the behavior by default
in JPA with default auto-commit?
1-
Flush every time before query
2-
Flush only when a too complex query cannot execute in memory
3-
Default to get stale issue by not flushing when should
What was positive with the product before JPA, was ease of use
for simpler application, because provided Workbench for mapping with some
validation. Less cascading options made it look simpler.
Thanks for
sharing this info; I feel Eclipselink Expression API is more intuitive
than JPA Criteia API  ;
I'm actually trying to compare
and contrast the Session Broker architecture in EclipseLink and the Hibernate
Shards;
and observed a major difference between
the two.
Here is a summary of what Session Broker is not:
Session Broker Session Limitations
Although the session broker is a
powerful tool that lets you use data that is distributed across multiple
databases from a single application, it has some limitations:
·
You cannot split multiple table descriptors
across databases.
·
Each
class must reside on only one database.
·
You cannot use joins through expressions across
databases.
·
Many-to-many join tables must reside on the same
database as the target object (See "Many-to-Many
Join Tables and Direct Collection Tables" for a work-around for this
limitation).
Here is what Hibernate Shards is:.
Hibernate Shards addresses the problem of Horizontal
parititioning by facilitating a single view ( Java Class ) of the
data that may reside across several database servers which essentially means
all mapped schema would be identical across all the servers, and Hibernate
Shards provides a way to the developers to store different set of records(rows)
on different database servers based on predefined/user-extended algorithm.
So, in hibernate shards, most probably Each class will reside on every database.
I believe EclipseLink has the infrastructure to handle
these kind of use cases but it needs a little dressing up of the existing
Session Broker architecture.
Sorry for repeating my earlier question, Can I log feature
request asking for eclipselink to support Horizontal Partitioning
( Others may suggest Vertical Partitioning as well)? These advanced
database design/maintenence strategies are very much essential for the birth of
sites like twitter, linkedin, facebook, etc in Java.
On Fri, Jun 19, 2009 at 12:52 AM, Douglas Clarke <DOUGLAS.CLARKE@...> wrote:
Samba,
At JavaOne (CommunityOne) I presented and EclipseLink talk focussed on our JPA
2.0 support. I highlighted the following example of using our expression/query
API.
> JP QL:
SELECT e FROM Employee e WHERE e.name
LIKE ‘D%’
> EclipseLink Expressions:
ExpressionBuilder eb = new ExpressionBuilder();
ReadAllQuery q = new ReadAllQuery(Employee.class, eb);
q.setSelectionCriteria(eb.get(“name”).like(“D%”));
List<Employee> results = JpaHelper.createQuery(em, q).getResultList();
> JPA 2.0 Criteria:
QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery q = qb.create();
Root emp = q.from(Employee.class);
q.select(emp);
q.where(qb.like(emp.get(“name”), “D%”));
List<Employee> results = em.createQuery(q).getResultList();
I just wanted to show how the JPA 2.0 criteria API aligns with our existing
expression/query framework and how the JpaHelper class can be used.
Doug
-----Original Message-----
From: Samba [mailto:saasira@...]
Sent: Thursday, June 18, 2009 2:30 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] Eclipselink Vs Hibernate
James,
Thanks for your response.
Its good to know that Eclipselink Expression API is
detached and I just came to know that we can use these expressions with
((JpaEntityManager)entityManager.getDelegate()).createQuery(Expression
expression, Class resultType);
method which returns the standard JPA Query object.
Also thanks again for letting me know about JSR-303, the Bean
Validation Specification.
In addition to this, I'm interested in knowing a little more
about Eclipselink's SessionBroker architecture.
Is this feature exposed through the JPA entity manager API?
Something like persistence xml property extentions to specify the
session broker configuration xml file would be very helpful.
It would be great if the JpaEntityManager class makes using the
Session Broker transparent of the internal session manager and session broker
details.
If doing these are not possible as of now, can these be taken as a
feature request?
Thanks and Regards,
Samba
On Thu, Jun 18, 2009 at 1:39 AM, James Sutherland <jamesssss@...> wrote:
I'm not very familiar with these Hibernate extensions, so will do my best to
comment on this.
First off, EclipseLink offers many advanced features not in Hibernate:
- Moxy - object-XML mapping and JAXB
- SDO
- DBWS - database webservices
- EIS
- OR data-type mappings
- Caching and cache coordination
- extended Oracle database and JDBC integration
- TopLink Grid uses EclipseLink
Also many new features are being developed in EclipseLink 2.0 as the JPA 2.0
reference implementation, including the criteria API.
1. Hibernate Validator
- From Hibernate's website this seems to be obsolete, or replaced with
"JSR
303: Bean Validation". So would seem to have little to do with
Hibernate
any more, and any such implemention could be used with any persistence
product including EclipseLink.
2. Hibernate Search
- I think Lucene also has an EclipseLink integration.
3. Enhanced Query Facilities like the DetachedCriteria and the HQL on top of
JPQL
- EclipseLink Expressions are always detached, and can even be serialized.
- EclipseLink is adding many JPQL enhancements as part of JPA 2.0.
4. Threadsafeness and Non-blocking data access
- EclipseLink is always thread-safe and non-blocking, and extensive work is
put into ensuring EclipseLink is the most peformant persistence product.
5. Hibernate Shards
- I'm not that familiar with this, but I believe it is similar to
EclipseLink's SessionBroker feature.
saasira wrote:
>
> Hi,
>
> May I request the eclipselink community to enlighten me on certain
> aspects
> of eclipselink where I could not find convincing answers when eclipselink
> is
> compared with hibernate?
> Before I start let me make it very clear that I'm not a hibernate
fan
> and
> I just want to confirm that eclipselink is not lagging behind in certain
> areas where hibernate advertises
> that it excels; on the other hand I don't want to bring back the
> infamous
> ORM wars with this mail :)
>
> To start with, here are the feaures the hibernate website
highlights:
>
> 1. *Hibernate Validator* <https://www.hibernate.org/412.html>
> 2. *Hibernate Search* <https://www.hibernate.org/410.html>
> 3. Enhanced *Query Facilities* <https://www.hibernate.org/347.html>,
> like the DetachedCriteria and the HQL on top of JPQL
> 4. Threadsafeness and Non-blocking data access
> 5. Google Contributed *Hibernate
> Shards*<https://www.hibernate.org/414.html>
>
>
> I know how simplified and powerful Eclipselink native
Expression API is
> (should I tell you how much I loathe the hibernate criteria API? ), but
> not
> sure if it can be used when the database session is closed, for
> example to build the query from UI layer; and I did not find any JPQL
> enhancements either by eclipselink.
>
> Also, I found in my googling a search library called Compass
which is
> based on Lucene that can be used with eclipselink for searching, but not
> sure how eclipselinkish ( if i can use the word ) its API is while on the
> other hand hibernate search is very much integrated with hibernate core.
>
> When it comes to shards, I think eclipselink does not have
this as of
> now
> (may this be taken as a feature request?).
>
> Please correct me if have presented anything wrongly here; my
intention
> is to get a better picture of where eclipselink stands when compared
to
> hibernate in the above said feature list.
>
> I know hibernate is no match when it comes to the breadth of the
variety
> of datasources that eclipselink supports; but I want to narrow the
> comparision to where hibernate has some foothold and can
> compete with the monster :)
>
> The reason I'm doing this is to fight with my friends who work on
> hibernate and tell them that theirs is not the whole world and much more
> lies out side of the confines they have set themselves in.
>
> Thanks and Regards,
> Samba
>
>
-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com
James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink
EclipseLink ,
http://wiki.oracle.com/page/TopLink
TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48
TopLink ,
http://www.nabble.com/EclipseLink-f26430.html
EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java
Persistence
--
View this message in context: http://www.nabble.com/Eclipselink-Vs-Hibernate-tp24041213p24081107.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
RE: Eclipselink Vs Hibernate
Some parts of this message have been removed.
Learn more about Nabble's security policy.
There
are a couple of issues in this last post I would like to add my thoughts
on.
1.
Caching
How
the two frameworks handle caching is one of the primary differentiators.
Hibernate's caching of rows offers a certain simplicity that is one of the
reasons it supports pluggable caching more directly. EclipseLink on the other
hand caches the mapped objects. Caching the mapped objects has its challenges
but over the past 12 years of working with customers using it I have found its
benefits to be worth it. When applications have shared data the performance
cost of rebuilding objects from the row for each usage and the effects on
memory usage versus the possibility of using the same shared instance
should not be ignored.
EclipseLink's object caching and out of the box support for cache
coordination offer impressive benefits. These benefits are greater if there
are more entity types that are read-only (reference data) or read-mostly. For
those more volatile types in the application the developer can easily tune
when EclipseLink re-loads from the database or choose not to store these types
in the shared cache. The caching solution now available in EclipseLink has
evolved over a long period of time based on feedback from the community with
tuneable options to address many different usage scenarios.
We believe strongly in the approach we have taken and its
benefits.
On
the pluggability side we have taken steps to extend our caching solution with
cache interceptors. The intent was to enable grid style solutions to be
plugged in with EclipseLink. Oracle TopLink leverages these extensions to
enable its TopLink Grid functionality integrating Coherence. If there is
interest in plugging in other similar solutions we would be happy to
assist.
The
only caution I offer to users taking up any ORM
solution is to learn how the caching works and tune it for their applications
requirements.
2.
Partitioning
The
discussion of EclipseLink SessionBroker versus Hibernate Shards may not be a
good comparison. Both offer value but have narrow usage scenarios.
SessionBroker allows multiple databases to be combined together with a single
Session facade where the data is split across databases/schemas by type.
Shards appears to address a different type of partitioning where the same
tables exist in each database/schema and the data is divided across the tables
based on some algorithm (http://en.wikipedia.org/wiki/Partition_(database)).
I
have assisted a few customers over the years in a horizontal partitioning of
their data similar to what I believe shards offers. Using EclipseLink event
framework we were able to send queries to different databases based on data
values and write changes back to the correct database. If there is a
demand for formalizing this support I would be very interested in working with
the community to capture the requirements and documenting how these can be met
with existing EclipseLink features or extending the framework to better
meet their needs.
Doug
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
Hi Sebastien,
Thanks a lot for taking time to compile the pressing issues in eclipselink, atleast those related to the topics that we discussed here;
I believe these kind of retrospective discussions will be ultimately helpful to the product and the community.
And it is good to know that you have fixed some existing issues in the Session Broker; I'll be looking forward for eclipselink bundles that have your solution to the problem, as is or adapted to the overall eclipselink architecture. It is good to see that the enhancement request raised by Doug himself (albeit low priority) is getting a solution from the community.
Every product has bugs and as long as the community is active, one need not worry too much as its only a matter of time before issues get fixed.
I believe the issues you mentioned like concurrency,locking and non-JEE-compliant JMS notifications are worth taking on with a priority higher than P3.
A dzone article about the issue mentioned in bug-274417, but related to fiddling with hibernate is here http://netbeans.dzone.com/news/netbeans-and-jpa-with-multiple ; it looks like several persons are trying to solve the same problem in their own way. Shouldn't it be addressed at the spec level as Doug mentioned in the comments for this bug?
I'm really surprised to hear that Session Broker is a dropped functionality; its value can be enormous for any project that has to be designed for scalability and performance. Perhapas the Giants like Oracle or DB2 may handle petabytes of data in a single database but not all database systems offer such luxury.
So, in order to be scalable we have to design our schema in such a way that the data is distributed across the clusters and no single node is drained out of resources at any point in time. Session Broker offers one of the ways to achieve this and the other being the Hibernate Shards approach; both seems to be solving the same problem but each in its own way, and each has its own applications.
Doug,
"EclipseLink code is not so easy to reuse/extend, probably because less users are stretching flexibility" ---- If there is any truth in this comment, don't you think a re-look at providing extention points is required?
Another question that comes to mind often is to estimate the amount of overhead at runtime spent by JPA wrapper to comminicate to and fro the native toplink code. Do you think if there is any possibility for this overhead to cause performance botttlenecks in a heavily loaded system? Has there been any tests written in this regard?
About Caching, I agree with Doug that many people would go with using eclipselink internal cache provider unless they have a more performant cache provider, or for intergating with distributed systems like Coherence or Gigaspaces. Nevertheless, these use cases cannot be ignored; hence providing hooks to plugin additional cache providers adds flexibility for eclipselink to be integrated with any system of user's choice. If there is any existing feature request regarding this issue, please let me know so that I can vote for it.
Another important feature request I would like to make is for eclipselink to support horizontal partitioning ( I think Vertical partitioning is very difficult to implement). Since you mentioned that you have earlier worked with a customer to achieve this with erstwhile toplink, I hope it would not be too much to ask for generalising that solution and adding it to eclipselink, perhaps to 2.0 trunk.
Thanks and Regards,
Samba
On Fri, Jun 19, 2009 at 6:16 PM, Douglas Clarke <DOUGLAS.CLARKE@...> wrote:
There are a couple of issues in this last post I would like to add my thoughts on.
1. Caching
How the two frameworks handle caching is one of the primary differentiators. Hibernate's caching of rows offers a certain simplicity that is one of the reasons it supports pluggable caching more directly. EclipseLink on the other hand caches the mapped objects. Caching the mapped objects has its challenges but over the past 12 years of working with customers using it I have found its benefits to be worth it. When applications have shared data the performance cost of rebuilding objects from the row for each usage and the effects on memory usage versus the possibility of using the same shared instance should not be ignored.
EclipseLink's object caching and out of the box support for cache coordination offer impressive benefits. These benefits are greater if there are more entity types that are read-only (reference data) or read-mostly. For those more volatile types in the application the developer can easily tune when EclipseLink re-loads from the database or choose not to store these types in the shared cache. The caching solution now available in EclipseLink has evolved over a long period of time based on feedback from the community with tuneable options to address many different usage scenarios. We believe strongly in the approach we have taken and its benefits.
On the pluggability side we have taken steps to extend our caching solution with cache interceptors. The intent was to enable grid style solutions to be plugged in with EclipseLink. Oracle TopLink leverages these extensions to enable its TopLink Grid functionality integrating Coherence. If there is interest in plugging in other similar solutions we would be happy to assist.
The only caution I offer to users taking up any ORM solution is to learn how the caching works and tune it for their applications requirements.
2. Partitioning
The discussion of EclipseLink SessionBroker versus Hibernate Shards may not be a good comparison. Both offer value but have narrow usage scenarios. SessionBroker allows multiple databases to be combined together with a single Session facade where the data is split across databases/schemas by type. Shards appears to address a different type of partitioning where the same tables exist in each database/schema and the data is divided across the tables based on some algorithm (http://en.wikipedia.org/wiki/Partition_(database)).
I have assisted a few customers over the years in a horizontal partitioning of their data similar to what I believe shards offers. Using EclipseLink event framework we were able to send queries to different databases based on data values and write changes back to the correct database. If there is a demand for formalizing this support I would be very interested in working with the community to capture the requirements and documenting how these can be met with existing EclipseLink features or extending the framework to better meet their needs.
Doug
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
RE: Eclipselink Vs Hibernate
Samba,
The
SessionBroker functionality has not been dropped. It simply has not been
integrated with our JPA implementation. It is completely supported through our
native API and is usable with our native metadata used through the JPA
interfaces.
The
solution Sebastien is working on is a broker type solution that implements JPA
and sits on top of multiple persistence units. This approach is a much better
fit with JPA as it exists now and in the proposed 2.0 specification. We also are
looking forward to any contribution Sebastien can make to our community in this
area.
Within
the EclipseLink committers working on the ORM/JPA end of things the focus is on
delivering the JPA 2.0 reference implementation within the Java EE 6 schedule.
This means bugs targeted for 2.0 that are not directly linked to this effort are
blocked behind it. Hopefully as the summer moves along and more of the 2.0 work
gets completed we'll have cycles to address the current bug backlog to get as
many issues possible resolved for the 2.0 release. We are working to make sure
that queue is appropriately prioritized and do make an effort to address user
contributed fixes as quickly as possible. If there is a bug you believe should
be higher prioritized please add your comments and vote for it. Our weekly open
meeting is also a good chance to discuss bugs that are of importance to
you.
>
"EclipseLink code is not so easy to reuse/extend,
probably because less users are stretching flexibility" ---- If there > is any truth in this comment, don't
you think a re-look at providing extention points is
required?
I
disagree completely with this statement.EclipseLink is completely extensible in
many dimensions. Over the last 12 years I have solved countless corner cases and
challenging customer requirements through use of event listeners, customizers,
and custom query types. As we add new functionality we continue to make sure its
usage is flexible and extensible.
JPA Overhead: When using EclipseLink through JPA
there are some different characteristics then when you use our native API. We
have exposed query hints such as read-only to allow customers who want more
direct access to avoid some of the additional cloning. We believe strongly in
JPA but also want to continue to offer our advanced mapping and performance and
scalability features through this standard API. It is also possible to mix in
use of the native API if there are scenarios where you feel this will meet your
needs better.
Horizontal Partitioning: I agree that we should
start a more formal effort up in this area. Possibly an incubator sub-project.
The key to making this work is participation from the community. Requirements,
reviews, and verification are key. I will try to at least get the ball rolling
on this but I would not expect much resourcing for this until the fall. If you
are interested in getting involved that would be great.
Hopefully I have touched on all of your points. If not maybe we can start
up separate threads for each to make it clear to everyone following this
discussion.
Doug
Hi Sebastien,
Thanks a lot for taking time to compile the pressing issues in eclipselink,
atleast those related to the topics that we discussed here;
I believe these kind of retrospective discussions will be ultimately
helpful to the product and the community.
And it is good to know that you have fixed some existing
issues in the Session Broker; I'll be looking forward for
eclipselink bundles that have your solution to the problem, as is or
adapted to the overall eclipselink architecture. It is good to see that the
enhancement request raised by Doug himself (albeit low priority) is
getting a solution from the community.
Every product has bugs and as long as the community is active, one need
not worry too much as its only a matter of time before issues get fixed.
I believe the issues you mentioned like
concurrency,locking and non-JEE-compliant JMS notifications are
worth taking on with a priority higher than P3.
A dzone article about the issue mentioned in bug-274417, but related to
fiddling with hibernate is here http://netbeans.dzone.com/news/netbeans-and-jpa-with-multiple ; it looks
like several persons are trying to solve the same problem in their own way.
Shouldn't it be addressed at the spec level as Doug mentioned in the comments
for this bug?
I'm really surprised to hear that Session Broker is a dropped
functionality; its value can be enormous for any project that has to be
designed for scalability and performance. Perhapas the Giants like Oracle or
DB2 may handle petabytes of data in a single database but not all
database systems offer such luxury.
So, in order to be scalable we have to design our schema in such a
way that the data is distributed across the clusters and no single node is
drained out of resources at any point in time. Session Broker offers one
of the ways to achieve this and the other being the Hibernate Shards
approach; both seems to be solving the same problem but each in its own
way, and each has its own applications.
Doug,
"EclipseLink code is not so easy to reuse/extend, probably
because less users are stretching flexibility" ---- If there is any truth in this comment, don't you
think a re-look at providing extention points is required?
Another question that comes to mind often is to estimate the amount
of overhead at runtime spent by JPA wrapper to comminicate to and fro the
native toplink code. Do you think if there is any possibility for this
overhead to cause performance botttlenecks in a heavily loaded system?
Has there been any tests written in this regard?
About Caching, I agree with Doug that many people would go with using
eclipselink internal cache provider unless they have a more performant cache
provider, or for intergating with distributed systems like Coherence or
Gigaspaces. Nevertheless, these use cases cannot be ignored; hence
providing hooks to plugin additional cache providers adds flexibility for
eclipselink to be integrated with any system of user's choice. If
there is any existing feature request regarding this issue, please let me know
so that I can vote for it.
Another important feature request I
would like to make is for eclipselink to support horizontal partitioning ( I
think Vertical partitioning is very difficult to implement). Since you
mentioned that you have earlier worked with a customer to achieve this with
erstwhile toplink, I hope it would not be too much to ask for generalising
that solution and adding it to eclipselink, perhaps to 2.0 trunk.
Thanks and Regards,
Samba
On Fri, Jun 19, 2009 at 6:16 PM, Douglas Clarke <DOUGLAS.CLARKE@...>
wrote:
There are a couple of
issues in this last post I would like to add my thoughts
on.
1.
Caching
How the two frameworks
handle caching is one of the primary differentiators. Hibernate's caching
of rows offers a certain simplicity that is one of the reasons it supports
pluggable caching more directly. EclipseLink on the other hand caches the
mapped objects. Caching the mapped objects has its challenges but over the
past 12 years of working with customers using it I have found its benefits
to be worth it. When applications have shared data the performance cost of
rebuilding objects from the row for each usage and the effects on
memory usage versus the possibility of using the same shared instance
should not be ignored.
EclipseLink's object
caching and out of the box support for cache coordination offer impressive
benefits. These benefits are greater if there are more entity types that
are read-only (reference data) or read-mostly. For those more volatile
types in the application the developer can easily tune when EclipseLink
re-loads from the database or choose not to store these types in the
shared cache. The caching solution now available in EclipseLink has
evolved over a long period of time based on feedback from the community
with tuneable options to address many different usage scenarios.
We believe
strongly in the approach we have taken and its benefits.
On the pluggability side
we have taken steps to extend our caching solution with cache
interceptors. The intent was to enable grid style solutions to be plugged
in with EclipseLink. Oracle TopLink leverages these extensions to enable
its TopLink Grid functionality integrating Coherence. If there is interest
in plugging in other similar solutions we would be happy to
assist.
The only caution I offer
to users taking up any ORM solution is to learn
how the caching works and tune it for their applications
requirements.
2.
Partitioning
The discussion of
EclipseLink SessionBroker versus Hibernate Shards may not be a good
comparison. Both offer value but have narrow usage scenarios.
SessionBroker allows multiple databases to be combined together with a
single Session facade where the data is split across databases/schemas by
type. Shards appears to address a different type of partitioning where the
same tables exist in each database/schema and the data is divided across
the tables based on some algorithm (http://en.wikipedia.org/wiki/Partition_(database)).
I have assisted a few
customers over the years in a horizontal partitioning of their data
similar to what I believe shards offers. Using EclipseLink event framework
we were able to send queries to different databases based on data values
and write changes back to the correct database. If there is a demand
for formalizing this support I would be very interested in working with
the community to capture the requirements and documenting how these can be
met with existing EclipseLink features or extending the framework to
better meet their needs.
Doug
_______________________________________________
eclipselink-users
mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
Thanks a lot Doug,
That is an exhaustive response and makes clear what the priorities at this moment are!
I agree with you that as the JPA 2.0 reference implementation, eclipselink-2.0 has to be stable by the time JEE-6 rolls out. It would be better to open another branch tagged 2.1 where we can address the backlog issues that are not directly related to JPA.
"Horizontal Partitioning:The key to making this work is participation from the community. Requirements, reviews, and verification are key'-- I can contribute in this regard to the best of my abilities.
Finally, thanks to James and Sebastien for participating in this discussion and making it lively; the spirit of the discussion is wonderful!
Regards,
Samba
On Fri, Jun 19, 2009 at 10:35 PM, Douglas Clarke <DOUGLAS.CLARKE@...> wrote:
Samba,
The SessionBroker functionality has not been dropped. It simply has not been integrated with our JPA implementation. It is completely supported through our native API and is usable with our native metadata used through the JPA interfaces.
The solution Sebastien is working on is a broker type solution that implements JPA and sits on top of multiple persistence units. This approach is a much better fit with JPA as it exists now and in the proposed 2.0 specification. We also are looking forward to any contribution Sebastien can make to our community in this area.
Within the EclipseLink committers working on the ORM/JPA end of things the focus is on delivering the JPA 2.0 reference implementation within the Java EE 6 schedule. This means bugs targeted for 2.0 that are not directly linked to this effort are blocked behind it. Hopefully as the summer moves along and more of the 2.0 work gets completed we'll have cycles to address the current bug backlog to get as many issues possible resolved for the 2.0 release. We are working to make sure that queue is appropriately prioritized and do make an effort to address user contributed fixes as quickly as possible. If there is a bug you believe should be higher prioritized please add your comments and vote for it. Our weekly open meeting is also a good chance to discuss bugs that are of importance to you.
> "EclipseLink code is not so easy to reuse/extend, probably because less users are stretching flexibility" ---- If there > is any truth in this comment, don't you think a re-look at providing extention points is required?
I disagree completely with this statement.EclipseLink is completely extensible in many dimensions. Over the last 12 years I have solved countless corner cases and challenging customer requirements through use of event listeners, customizers, and custom query types. As we add new functionality we continue to make sure its usage is flexible and extensible.
JPA Overhead: When using EclipseLink through JPA there are some different characteristics then when you use our native API. We have exposed query hints such as read-only to allow customers who want more direct access to avoid some of the additional cloning. We believe strongly in JPA but also want to continue to offer our advanced mapping and performance and scalability features through this standard API. It is also possible to mix in use of the native API if there are scenarios where you feel this will meet your needs better.
Horizontal Partitioning: I agree that we should start a more formal effort up in this area. Possibly an incubator sub-project. The key to making this work is participation from the community. Requirements, reviews, and verification are key. I will try to at least get the ball rolling on this but I would not expect much resourcing for this until the fall. If you are interested in getting involved that would be great.
Hopefully I have touched on all of your points. If not maybe we can start up separate threads for each to make it clear to everyone following this discussion.
Doug
-----Original Message----- From: Samba [mailto: saasira@...] Sent: Friday, June 19, 2009 12:38 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] Eclipselink Vs Hibernate
Hi Sebastien,
Thanks a lot for taking time to compile the pressing issues in eclipselink, atleast those related to the topics that we discussed here;
I believe these kind of retrospective discussions will be ultimately helpful to the product and the community.
And it is good to know that you have fixed some existing issues in the Session Broker; I'll be looking forward for eclipselink bundles that have your solution to the problem, as is or adapted to the overall eclipselink architecture. It is good to see that the enhancement request raised by Doug himself (albeit low priority) is getting a solution from the community.
Every product has bugs and as long as the community is active, one need not worry too much as its only a matter of time before issues get fixed.
I believe the issues you mentioned like concurrency,locking and non-JEE-compliant JMS notifications are worth taking on with a priority higher than P3.
A dzone article about the issue mentioned in bug-274417, but related to fiddling with hibernate is here http://netbeans.dzone.com/news/netbeans-and-jpa-with-multiple ; it looks like several persons are trying to solve the same problem in their own way. Shouldn't it be addressed at the spec level as Doug mentioned in the comments for this bug?
I'm really surprised to hear that Session Broker is a dropped functionality; its value can be enormous for any project that has to be designed for scalability and performance. Perhapas the Giants like Oracle or DB2 may handle petabytes of data in a single database but not all database systems offer such luxury.
So, in order to be scalable we have to design our schema in such a way that the data is distributed across the clusters and no single node is drained out of resources at any point in time. Session Broker offers one of the ways to achieve this and the other being the Hibernate Shards approach; both seems to be solving the same problem but each in its own way, and each has its own applications.
Doug,
"EclipseLink code is not so easy to reuse/extend, probably because less users are stretching flexibility" ---- If there is any truth in this comment, don't you think a re-look at providing extention points is required?
Another question that comes to mind often is to estimate the amount of overhead at runtime spent by JPA wrapper to comminicate to and fro the native toplink code. Do you think if there is any possibility for this overhead to cause performance botttlenecks in a heavily loaded system? Has there been any tests written in this regard?
About Caching, I agree with Doug that many people would go with using eclipselink internal cache provider unless they have a more performant cache provider, or for intergating with distributed systems like Coherence or Gigaspaces. Nevertheless, these use cases cannot be ignored; hence providing hooks to plugin additional cache providers adds flexibility for eclipselink to be integrated with any system of user's choice. If there is any existing feature request regarding this issue, please let me know so that I can vote for it.
Another important feature request I would like to make is for eclipselink to support horizontal partitioning ( I think Vertical partitioning is very difficult to implement). Since you mentioned that you have earlier worked with a customer to achieve this with erstwhile toplink, I hope it would not be too much to ask for generalising that solution and adding it to eclipselink, perhaps to 2.0 trunk.
Thanks and Regards,
Samba
On Fri, Jun 19, 2009 at 6:16 PM, Douglas Clarke <DOUGLAS.CLARKE@...> wrote:
There are a couple of issues in this last post I would like to add my thoughts on.
1. Caching
How the two frameworks handle caching is one of the primary differentiators. Hibernate's caching of rows offers a certain simplicity that is one of the reasons it supports pluggable caching more directly. EclipseLink on the other hand caches the mapped objects. Caching the mapped objects has its challenges but over the past 12 years of working with customers using it I have found its benefits to be worth it. When applications have shared data the performance cost of rebuilding objects from the row for each usage and the effects on memory usage versus the possibility of using the same shared instance should not be ignored.
EclipseLink's object caching and out of the box support for cache coordination offer impressive benefits. These benefits are greater if there are more entity types that are read-only (reference data) or read-mostly. For those more volatile types in the application the developer can easily tune when EclipseLink re-loads from the database or choose not to store these types in the shared cache. The caching solution now available in EclipseLink has evolved over a long period of time based on feedback from the community with tuneable options to address many different usage scenarios. We believe strongly in the approach we have taken and its benefits.
On the pluggability side we have taken steps to extend our caching solution with cache interceptors. The intent was to enable grid style solutions to be plugged in with EclipseLink. Oracle TopLink leverages these extensions to enable its TopLink Grid functionality integrating Coherence. If there is interest in plugging in other similar solutions we would be happy to assist.
The only caution I offer to users taking up any ORM solution is to learn how the caching works and tune it for their applications requirements.
2. Partitioning
The discussion of EclipseLink SessionBroker versus Hibernate Shards may not be a good comparison. Both offer value but have narrow usage scenarios. SessionBroker allows multiple databases to be combined together with a single Session facade where the data is split across databases/schemas by type. Shards appears to address a different type of partitioning where the same tables exist in each database/schema and the data is divided across the tables based on some algorithm (http://en.wikipedia.org/wiki/Partition_(database)).
I have assisted a few customers over the years in a horizontal partitioning of their data similar to what I believe shards offers. Using EclipseLink event framework we were able to send queries to different databases based on data values and write changes back to the correct database. If there is a demand for formalizing this support I would be very interested in working with the community to capture the requirements and documenting how these can be met with existing EclipseLink features or extending the framework to better meet their needs.
Doug
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
hi all
i believe that if ADF 100% opensource like eclipselink, the popularity
that eclipselink wanna to get (which in my opinion hibernate for
people that want ORM only is quiet enough)., will increase,
eclipselink will become key component in any development
but if we move to SOA etc, EclipseLink is the best, but there is SEam,
that help development like ADF , but Seam is opensource.
i think the movement will become cool if JSR 330 can be part of oracle ADF stack
this is because oracle in marketing way (my opinion) promote ADF more
than EclipseLink.
oracle makes the TopLink as part of ADF.
we need marketing promotion to increase EclipseLink marketshare, it is
not only cool product right, i think oracle more expert in this area.
F
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
For what it's worth, another comment on caching. Hibernate's approach seems to fit most naturally with the request/response cycles in webapps and outside that (e.g. batch processing, thick clients, ...) is often not ideal, at least in my experience. The last app I wrote first for Hibernate and then retargeted for EclipseLink. The reason was that it a bulk processing component using incremental flushes/commits with high throughput requirements.
With Hibernate I had to come up with various gross work-arounds to avoid flushing and rebuilding the extremely large first level cache. Without these hacks performance was impaired (apparently due to constantly rebuilding objects, etc.), whereas with EcliseLink's 'live' objects and other strategies this became essentally a non-issue. Naturally, caching live objects does have it's pitfalls: one needs to pay special attention when using full identity caching caching lest memory leaks ensue due to references pointing to elsewhere in the heap...
- Jason On Fri, Jun 19, 2009 at 6:46 AM, Douglas Clarke <DOUGLAS.CLARKE@...> wrote:
There
are a couple of issues in this last post I would like to add my thoughts
on.
1.
Caching
How
the two frameworks handle caching is one of the primary differentiators.
Hibernate's caching of rows offers a certain simplicity that is one of the
reasons it supports pluggable caching more directly. EclipseLink on the other
hand caches the mapped objects. Caching the mapped objects has its challenges
but over the past 12 years of working with customers using it I have found its
benefits to be worth it. When applications have shared data the performance
cost of rebuilding objects from the row for each usage and the effects on
memory usage versus the possibility of using the same shared instance
should not be ignored.
EclipseLink's object caching and out of the box support for cache
coordination offer impressive benefits. These benefits are greater if there
are more entity types that are read-only (reference data) or read-mostly. For
those more volatile types in the application the developer can easily tune
when EclipseLink re-loads from the database or choose not to store these types
in the shared cache. The caching solution now available in EclipseLink has
evolved over a long period of time based on feedback from the community with
tuneable options to address many different usage scenarios.
We believe strongly in the approach we have taken and its
benefits.
On
the pluggability side we have taken steps to extend our caching solution with
cache interceptors. The intent was to enable grid style solutions to be
plugged in with EclipseLink. Oracle TopLink leverages these extensions to
enable its TopLink Grid functionality integrating Coherence. If there is
interest in plugging in other similar solutions we would be happy to
assist.
The
only caution I offer to users taking up any ORM
solution is to learn how the caching works and tune it for their applications
requirements.
2.
Partitioning
The
discussion of EclipseLink SessionBroker versus Hibernate Shards may not be a
good comparison. Both offer value but have narrow usage scenarios.
SessionBroker allows multiple databases to be combined together with a single
Session facade where the data is split across databases/schemas by type.
Shards appears to address a different type of partitioning where the same
tables exist in each database/schema and the data is divided across the tables
based on some algorithm (http://en.wikipedia.org/wiki/Partition_(database)).
I
have assisted a few customers over the years in a horizontal partitioning of
their data similar to what I believe shards offers. Using EclipseLink event
framework we were able to send queries to different databases based on data
values and write changes back to the correct database. If there is a
demand for formalizing this support I would be very interested in working with
the community to capture the requirements and documenting how these can be met
with existing EclipseLink features or extending the framework to better
meet their needs.
Doug
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
|
Re: Eclipselink Vs Hibernate
Hi,
I am Compass project lead and wanted to explain a bit about the integration of Compass and EclipseLink. Basically, in terms of functionality, Compass is years ahead of anything Hibernate Search has to offer (you are welcomed to check the docs and compare yourself).
Regarding how well it integrates with EclipseLink, Compass has several modes, while one of the them (the simplest), is an "embedded" mode within EclipseLink. It is a similar integration to how Hiberante Search integrates with Hibernate core, except for the fact that Compass API does not extend JPA EMF/EM (and with good reason, since Compass can be used in standalone manner).
One of the nice things about Compass and its integration with JPA is the fact that the integration is agnostic to the JPA provider, and similar integration (minor configuration changes) will work with all current JPA providers.
If there are any specific questions regarding the integration, the Compass forum is the place to go. I heard of many successful users that are very happy with Compass integration and EclipseLink (or TopLink).
Cheers,
Shay
saasira wrote:
Hi,
May I request the eclipselink community to enlighten me on certain aspects
of eclipselink where I could not find convincing answers when eclipselink is
compared with hibernate?
Before I start let me make it very clear that I'm not a hibernate fan and
I just want to confirm that eclipselink is not lagging behind in certain
areas where hibernate advertises
that it excels; on the other hand I don't want to bring back the infamous
ORM wars with this mail :)
To start with, here are the feaures the hibernate website highlights:
1. *Hibernate Validator* < https://www.hibernate.org/412.html>
2. *Hibernate Search* < https://www.hibernate.org/410.html>
3. Enhanced *Query Facilities* < https://www.hibernate.org/347.html>,
like the DetachedCriteria and the HQL on top of JPQL
4. Threadsafeness and Non-blocking data access
5. Google Contributed *Hibernate
Shards*< https://www.hibernate.org/414.html>
I know how simplified and powerful Eclipselink native Expression API is
(should I tell you how much I loathe the hibernate criteria API? ), but not
sure if it can be used when the database session is closed, for
example to build the query from UI layer; and I did not find any JPQL
enhancements either by eclipselink.
Also, I found in my googling a search library called Compass which is
based on Lucene that can be used with eclipselink for searching, but not
sure how eclipselinkish ( if i can use the word ) its API is while on the
other hand hibernate search is very much integrated with hibernate core.
When it comes to shards, I think eclipselink does not have this as of now
(may this be taken as a feature request?).
Please correct me if have presented anything wrongly here; my intention
is to get a better picture of where eclipselink stands when compared to
hibernate in the above said feature list.
I know hibernate is no match when it comes to the breadth of the variety
of datasources that eclipselink supports; but I want to narrow the
comparision to where hibernate has some foothold and can
compete with the monster :)
The reason I'm doing this is to fight with my friends who work on
hibernate and tell them that theirs is not the whole world and much more
lies out side of the confines they have set themselves in.
Thanks and Regards,
Samba
_______________________________________________
eclipselink-users mailing list
eclipselink-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
