Sunday, June 16, 2013

Moving from Hibernate to EclipseLink - some first impressions

Generally spoken, it has been some work to remove all the non JPA Hibernate stuff from the code before I could even compile with eclipselink. Typically these have been Cache Annotations (Which I will now need from Eclipselink, standard is poor in this area). And I had some usages of ScollableResult that I had to remove. Hibernate seemed to apply some more defaults than EclipseLink does. I had to add @Temporal to my Date fields, when Hibernate was happy with a plain Date. For the queries I had to touch almost all of them adding aliases, where hibernate was happy without. (select from Class c where vs. select from Class where name) All in all it took me about a day for a project with around 100 Queries and 50 Domain Objects. Now I am investigating the Mutlti-Tenancy features of eclipselink, think I will give some feedback when I got feedback on my bugzillas :)


Lukas Eder said...

I'm curious, what made you migrate in the first place?

Thomas Kratz said...

Hi Lukas,

at most it's motivated by the relaxed lazy loading features of eclipselink. i.e. lazy load after transaction commit. Hibernate has a strict philosophy there.

Cheers Thomas

The Teknologist said...

Hi Thomas,

Same her. Lazy and Hibernate is a pain in the ass. I'd rather use stateless ejb with transaction persistence unit, rather than a collection of stateful ejbs with extended persistence context.

EclipseLink just suits better a stateless oriented hybrid application with rest endpoints and jsf UI frontend. I just can't understand why Hibernate nowadays still sticks to that...

Using Mapstruct with Protobuf3