openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: OpenJPA rock and fetch plan is a killing feature.
Date Tue, 01 Feb 2011 15:03:14 GMT
Am 01.02.11 14:41, schrieb Daryl Stultz:
> On Mon, Jan 31, 2011 at 5:18 PM, Jean-Baptiste BRIAUD -- Novlog<
>>  wrote:
>> Fetch path, fetch plan, ... : the same good idea with probably small
>> implementation differences in different products.
> Yes, Ebean does have an analogous feature to Fetch Plan. I was referring to
> auto-tuning of queries:
> So "fetch plan" available when needed but often not needed. I don't think
> this is a "small implementation difference".
Actually sorry to talk about an alternative orm here, I prefer OpenJPA 
over any other jpa implementation. But having used Ebean for a while 
really has opened my eye on how an orm implementation should work.
First of all it is not the fetch plans and the fetch profiling, there 
are so many other things which ebean does right over JPA.
For instance a criteria API which is actually a joy to use instead of 
having to go through 10.000 indirections you simply use something along 
the lines of select().from(Table.class).where().like("a","value%")

then you cannot run into lazy loading or detachment exceptions at all 
because the entities keep their delta state and the persistencecontext 
is mostly a cache nothing else. The worst you can get is a speed hit.

Then there is no flush which synchronizes the cache and maybe flushes 
some stuff you have altered but you dont want to save but you have full 
control on what should be saved as default behavior.

Also it has better sql integration if you need to go to the raw iron 
etc...  The list of things Ebean has done better compared to jpa is 
pretty long.

Sorry I am now mostly calm, but I have a feeling Ebean is somewhat 
overlooked while it does things really right in 99% of all cases, while 
JPA is somewhere at 80%.


View raw message