[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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@xxxxxxxxx> 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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
