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

[Francisco Peredo <franciscoperedo@xxxxxxxxxxxxxx>]

Thanks for answering, seems like EclipseLink is less limited than Hibernate
but not as feature rich as Cayenne? I inferred that because you did not
answer the question about validation support (does EclipseLink have anything
like it? would it be possible to build it?) and also did not answer the
question about temporal "before database insert" object ids... are they
supported?

I agree with you about IDENTITY sequencing, I would never recommend anyone 
to use IDENTITY sequencing, but sadly sometimes (in my case a lot of times)
one has to connect to a legacy database that is used by many systems and
that already uses IDENTITY sequencing, and therefore it is not something one
can choose not to use. For those cases... is EclipseLink also warrantied not
to "insert on persist" ? (In Hibernate persisting an object with IDENTITY
sequencing triggers a flush, which in turn triggers the Insert)

In Cayenne Classic API objects that have be registered in th ObjectContext
but never persisted in to the database are in a different state than those
that have already been persisted in to the database... is that also true for
EclipseLink? In Hibernate, there appears to be no support for this
intermediate state for objects with a compound id or a manually set id... is
this supported by EclipseLink?

In EclipseLink the foreign relationships mapped in the compound primary key
have to be on a OneToOne relationship for cascading to work (that is what
you seem to imply in your last post)? or does it also work for ManyToOne
relationships?


James Sutherland wrote:
> 
> 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
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Looking-for-the-ORM-that-best-matches-my-needs-tp22474341p22478920.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.