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. 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. 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. 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. 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. OK I'll get off ny soap box now. Chris -----Original Message----- From: Kevin Sutter [mailto:[email protected]] Sent: Wednesday, 12 May 2010 1:22 AM To: [email protected] 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 < [email protected]> 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 <[email protected]> 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] [email protected] > > [2] https://issues.apache.org/jira/browse/OPENJPA > > > > On Tue, May 11, 2010 at 9:12 AM, C N Davies <[email protected]> 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 > > > > > > > > > > > > > > >
