openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: JPA 3.0
Date Wed, 12 May 2010 15:04:08 GMT
Hi Chris,
Fairly loaded response...  :-)  As with any "new" technology, some features
of past technologies will still be missing.  Some of these features are
skipped on purpose (let's see if these are really required), others are
still on the plate but couldn't contain in the current release, and others
are just accidentally missed.

As you pointed out, many of these short-comings are due to the "design by
committee" approach.  But, just to defend the process a bit, I will say that
the JPA Expert Group actually worked quite well together.  The primary
voices were IBM, Oracle/Sun, Hibernate, and SAP.  Depending on the specific
feature being discussed, various members took the spotlight and drove that
feature.  But, everybody had a voice.  There was not a single, prominent
member that drove the spec (like I've heard of other specs).

Given that introduction, I'll provide a bit more response to your individual
paragraphs below...

And, I would suggest that if you feel strongly about any of these JPA
concerns, please post them to the JSR 317 feedback mailing list.  Thanks!

Thanks,
Kevin

On Tue, May 11, 2010 at 11:06 AM, C N Davies <cnd@cndavies.com> wrote:

> Thanks Kevin,
>
> I'll take a look and happy to get involved rather than bitch from the
> sidelines, I hate people who do that! :)
>
> My issues are frankly not bugs,  just what I'd term "Committee design
> decisions"  one of the down sides of the community process.  I know at
> least
> 5 people specifically who stopped using  OpenJPA blaming Apache when it's
> the JPA spec.  Number one frustration is the entity state,  who cares how
> JPA manages the entity, it should be transparent to the developer, we
> develop applications and use a database because it knows how to be a
> database. Why do I have to implement functionality to check if my entity is
> detached and handle it accordingly? Record and field level locking were
> well
> implemented in my first CPM ISAM file based experience using Canon Basic
> back, or SVR 4 in the 80's. I still use a DOS based Btrieve TSR for a huge
> POS system I developed about 20 years ago that seems to be able to handle
> these things transparently.
>

It's a matter of flexibility.  There are many client/server applications
that do not require the constant persistence context association.  Knowing
when it is okay and not okay to assume database availability is necessary
for best efficiency.  Both from an application viewpoint as well as from the
JPA runtime perspective.  I do agree that some of the processing gets
confusing depending on whether the Entity state is detached or not.  But, it
does provide much flexibility for the various applications that use the JPA
technology.


>
> JPA 2.0 "group by" rules were clearly designed by a DBA or Debian puritan,
> Oracle, MSSQL, MySQL and DB2 seem to be able to handle group by statement
> not including the all aggregated fields in the select statement, yet JPA 2
> requires it.  IMHO it should be a configuration property. If your Debian
> MySQL instance tries to force you to use it then turn it on, if you company
> DBA requires you to use it, then turn it on. If not the spec should allow
> you to turn it off.
>

:-)  I will agree that some of the expert group members are more DBA-like
than I am.  I kind of get pigeon-holed into DB2 capabilities, but other
members make sure that the solution is more generic and usable by other
database vendors.  The whole "pessimistic locking" mechanism was also
difficult to design by committee due to the differences in database
capabilities.  This particular "group by" concern would be an excellent
feedback item for the expert group.


>
> Fetch groups,  great idea but the surely JPA should be smart enough to work
> out that my lazy loaded collection should still be lazy loaded even is I
> call "size()"  on the lazy loaded collection. Instead I have to maintain a
> separate field in my enclosing entity and keep it in sync with the actual
> size of the lazy loaded collection, so it can actually be lazy loaded.
> Basically regress the quality of my design to what I would have done about
> 20 years ago.
>

I'm assuming you are referring to the OpenJPA Fetch Groups now (not specific
to a JPA spec feature).  This particular problem is something that should be
addressed via an OpenJPA JIRA.


>
> Having used commercial ORMS implementations for eh last 10 years,  JPA is
> very limited. Here's an example of how I can do it right now in a
> commercial
> app.
>
>
> Entity ent = Main.getSession().get(Class, Object[] keys);
> ....
> Do something with it
> ....
> Main.getSession().put(ent);
>
>
> Looks like JPA,  but notice I don't have to create an entity manager, I
> don't have to check if I have to merge or not,  don't have to check the
> attachment state. I can give it to a grad and he/she can use the paradigm.
> I don't have to constantly create and close entity managers all over the
> place. I guess the basic idea is that IMHO JPA 3 should be based more
> around
> an application model so the developer instantiates a persistence session
> that is application global and the JPA implementation manages the
> persistence.
>

In a way, your getSession() corresponds to an EM.  But, in this example, you
would have to maintain the lifecycle of the EM.  Running in a Container
environment simplifies this greatly.  The EM could be automatically injected
and associated with the transaction context.  And, the merge() method can be
used for both new and updated Entities.


>
> So far I have not been convinced that EJB 3 had done much more than save
> the
> developer writing a few queries, but what I can tell you it has increased
> our development costs significantly, as we have to redesign apps and
> developers spend more crazy amounts of time trying to get JPA 3 to deliver
> similar performance and functionality as EJB 2. We actually turned a major
> project around mid way through our development schedule to get off JPA and
> go back to native Hibernate and basic JDBC.
>

That's not a good promotion for JPA...  :-(  We have actually heard the
opposite from customers moving from more specific JDBC applications.  If
customers are currently writing their own SQL and JDBC calls, the move to
JPA is very much welcome.  Hides all of that gorp of interacting with the
database and fluffing up the result sets is something that JPA helps with
greatly.  Especially if you are using multiple databases.

We have done many, many improvements to the OpenJPA runtime to help with
performance.  Comparing the JPA runtime to JDBC is still tough, but we are
very close.  All of our benchmarks comparing to EJB 2 have never shown EJB 2
performing better than JPA.  But, with all benchmarks, it all depends on the
application.  We do many of our benchmark comparisons using DayTrader and
SpecJApp.  The most recent SpecJApp results with WebSphere and the JPA 2.0
Feature Pack (which uses OpenJPA 2.0) are quite impressive [1].

[1]
http://www.spec.org/jEnterprise2010/results/res2010q2/jEnterprise2010-20100407-00010.html
      http://www.spec.org/jEnterprise2010/results/jEnterprise2010.html


>
> OK I'll get off ny soap box now.
>

Me too...  :-)

Take care,
Kevin


>
> Chris
>
>
>
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Wednesday, 12 May 2010 1:22 AM
> To: users@openjpa.apache.org
> Subject: Re: JPA 3.0
>
> Hi Christopher,
> You're right, annotations can be verbose.  But, they don't have to be.  It
> all depends on whether your application can live with the default
> processing
> defined by the spec.  We tried to pick the most common default values for
> the various annotation elements.  If your application can live with the
> default processing, then all that is really necessary is the @Entity and
> @Id
> annotations.  But, most legacy applications and schemas can not live with
> the default settings, thus the annotations can become verbose.  Flexibility
> can be a killer...  But, then we'd be crucified if we didn't allow for the
> flexibility...  :-)
>
> The annotations can also be overridden via orm.xml declarations.  This
> would
> keep your base code more readable, while putting the detailed gorp into the
> xml file(s).  Maybe this would be more suitable for your environment.
>
> Not sure what you mean by "fluent API".  Any specific examples to help with
> this discussion?
>
> Thanks,
> Kevin
>
> On Tue, May 11, 2010 at 10:10 AM, Christopher Gardner <
> chris.r.gardner@gmail.com> wrote:
>
> > Vis-a-vis all JPA specs, streamlining annotations would be nice.  The
> > annotations can be verbose.  Maybe a fluent API would be in order.
> >
> > On Tue, May 11, 2010 at 10:46 AM, Kevin Sutter <kwsutter@gmail.com>
> wrote:
> >
> > > Hi Chris,
> > > Sorry to hear that you are frustrated with JPA 2.0.  Can you elaborate?
> > >  The
> > > JPA Expert Group is currently soliciting feedback for the next revision
> > of
> > > the JPA spec (2.x or 3.0).  Here's the e-mail address for this
> > > correspondence [1].  But, if there are distinct improvements that are
> you
> > > looking for, maybe they could be entertained by the OpenJPA community
> > > first.  Bugs and/or Features can be entered into our JIRA system [2]
> for
> > > future consideration.  Of course, community involvement can help speed
> up
> > > this process.
> > >
> > > Thanks for the input,
> > > Kevin
> > >
> > > [1]  jsr-317-feedback@sun.com
> > > [2]  https://issues.apache.org/jira/browse/OPENJPA
> > >
> > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <cnd@cndavies.com> wrote:
> > >
> > > > I'm so frustrated by JPA 2.0 but can't seem to find an JSR for JPA 3
> or
> > > > anything. Can anyone point me it?
> > > >
> > > >
> > > >
> > > > Thanks J
> > > >
> > > >
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message