openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: OpenJPA rock and fetch plan is a killing feature.
Date Tue, 01 Feb 2011 15:08:30 GMT
Hi Werner!

The BIG benefit eBeans has over _any_ JPA implementation is that it is solely made for optimistic
locking scenarios only. This eases lots of the pain we face in OpenJPA. Sure, pessimistic
locking isn't used that often, but we just cannot tune things easily as if we could by focusing
to optimistic locking only.

LiegGrue,
strub


--- On Tue, 2/1/11, Werner Punz <werner.punz@gmail.com> wrote:

> From: Werner Punz <werner.punz@gmail.com>
> Subject: Re: OpenJPA rock and fetch plan is a killing feature.
> To: users@openjpa.apache.org
> Date: Tuesday, February 1, 2011, 3:03 PM
> Am 01.02.11 14:41, schrieb Daryl
> Stultz:
> > On Mon, Jan 31, 2011 at 5:18 PM, Jean-Baptiste BRIAUD
> -- Novlog<
> > j-b.briaud@novlog.com> 
> wrote:
> > 
> >> http://www.avaje.org/ebean/introquery_join.html
> >> 
> >> 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:
> > http://avaje.com/ebean/introquery_autofetch.html
> > 
> > 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%.
> 
> :-)
> 
> 


      

Mime
View raw message