Re: [eclipselink-users] Looking for the ORM that best matches my needs

[James Sutherland <jamesssss@xxxxxxxxx>]

Wow, that is a mouthful, I will do my best to answer each of these questions.

1 - IDENTITY sequencing
First off, I would never recommend you use IDENTITY sequencing, such as in
MySQL, not just because of these issues, but because it does not support
pre-allocation, so you at best get poor performance.  Either use SEQUENCE
sequencing if your database supports it, otherwise TABLE sequencing, which
is quite efficient, especially in EclipseLink as we allocate the sequences
in a separate transaction.

Calling persist() in EclipseLink does not trigger the object to be inserted. 
Only calling flush() or commit() (or triggering a flush) will cause the
object to be inserted.

If you have an object with its id through a OneToOne mapping, the JPA
solution is to make the duplicate Basic read-only by making it
insertable/updateable=false.  This will allow you to related all your new
objects and commit and have all the ids assigned correctly.  EclipseLink
also supports not having the duplicate Basic at all and using the OneToOne
foreign key as part of the primary key, this removes the issue entirely,
even when using IDENTITY sequencing.

2 - Dirty
JPA does not have an isDirty API, but EclipseLink has extensive such API. 
If you access the EclipseLink UnitOfWork from the EclipseLink
JpaEntityManager you can get the current UnitOfWorkChangeSet that lists the
exact changes for all objects.  You can also cast any weaved object to the
ChangeTracker interface and get its current ChangeSet using
_persistence_getPropertyChangeListener() and
AttributeChangeListener.getObjectChangeSet().  There is also an extensive
event mechanism that also exposes the change sets.

3 - Nested contexts
JPA does not current support this, but the EclipseLink's native API fully
supports nested UnitOfWork.  From a UnitOfWork you can acquire a nested
UnitOfWork which isolated a nested set of changes that commits to its
parent.


Francisco P. wrote:
> 
> My first contact with an ORM was NextStep EOF... an ever since I have felt
> that nothing compares to it .
> 
> The thing is, I have had to work with JPA/Hibernate for a few years now...
> and I feel it has some weaknesses I really do not like, I am thinking
> about "switching to something else" but first i would like to be sure that
> the ORM I switch to does not have this weaknesses too. 
> 
> List of weaknesses in JPA/Hibernate: 
> 
> -No way to manage an object that "will be persisted", in JPA/Hibernate if
> you call entityManager.persist(object) and the database does not support
> sequences (like MS-Sql) an insert will be triggered, and if any of the non
> nullable fields of the objects is null, it will crash. If your object has
> a compound primary key, things get worse, because the entityManager can
> not deal with it until the compound primary key is set, and if your
> compound primary key is formed by foreign keys pointing to objects that
> are new too, that means you will not be able to save stuff with with a
> simple single call to entityManager.persist to one of the objects,
> cascading will not help you (I really miss something "magic" like the
> single shot EditingContext.commitChanges() in EOF)
> 
> -No easy way to know if "an object is dirty" (if it has changed/deleted
> since it was read from the database, there is just no API for that), and
> since you can not know what objects will be persisted, and what object
> have changed, and what objects will be deleted from database, that means
> you can not easily create an unified API for centralized polymorphic
> validation (that is no easy way to create validateForSave, or
> validateForDelete methods in your persistent entity classes)
> 
> -No real equivalent for validateForXXX, JPA lifecycle callbacks are not
> match for validateForXXX because you can not query the database during the
> lifecycle callbacks, and if you throw an exception inside a lifecycle
> callback, the JPA/Hibernate entityManager enters an invalid state, and
> after that you can not continue to use your POJOs, you have to start over
> with a fresh entityManager... and without you modifications to the POJOs.
> Note that Hibernate new validation framework does not offer a real
> solution for this problem... and AFAIK JSR-000303 will not help with this
> either.
> 
> -No support for some kind of temporary id: In JPA/Hibernate, the id for an
> object is "null" until you flush it to the database, so if you need to
> reference a particular object instance from the user interface... there is
> plain no way to do it, you have to "save it first" to get a primary key.
> 
> -No support for Nested Contexts... ( I think they would be a perfect fit
> for conversational frameworks like Seam or Shale). One of the goals of the
> ObjectContext is to provide an isolated area where local object changes
> can be performed without affecting other similar areas or the underlying
> storage. Nested Context changes can be saved to the parent Context without
> saving them to the database. Such child context is often called "nested".
> Nested contexts are useful in many situations, such as nested UI dialogs,
> complicated workflows, etc.
> 
> Those are my main disagreements with the way I have to work with
> JPA/Hibernate... will switching to
> JPA/EclipseLink help me with those? Apparently Cayenne, another ORM still
> in its way to become JPA complaint does not have any of this weaknesses
> (see
> http://www.nabble.com/Coming-from-EOF%3A-Cayenne-vs-Hibernate-to22463349.html
> for the answer to a very similar question in Cayenne forum), so I have
> been wondering... are this limitations an intrinsic part of the JPA
> standard and therefore EclipseLink shares this weaknesses (and Cayeenne
> will have to act as if were limited by them too while used with the the
> JPA complaint API) , or are this abstraction leaks in the way
> JPA/Hibernate works that are not shared by other JPA implementations (like
> EclipseLink)?
> 
> Thanks,
> 
> Regards,
> 
> LuxSpes
> 


-----
---
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/Looking-for-the-ORM-that-best-matches-my-needs-tp22474341p22478491.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.