Pinaki: Thank you for your insights on JPA and on the Criteria API. This is helpful even if I do not agree on the details of the decisions that were made. I don't have the benefit of being privy to the discussions which shaped JPA 2.0 and appreciate hearing your views.
I have found that JPA works best when amount of application logic residing in the database in minimized. If you can survive without triggers / stored procedures / views / etc., then the abstraction provided by JPA is quite successful. As you say, "OpenJPA kernel does not even depend or assume that the underlying database is relational or JDBC-aware". This is notable and commendable. The difficulty is in those situations where JPA must coexist with logic residing in the database. The text search example that I give is one such instance where functional considerations force coexistence. Another impetus might be organizational policies, such requirements that security and/or validation rules be imposed at the DB level. In each case, I would hope to benefit from JPA without resorting to a lower level syntax such as JDBC. You present diametric schools of thought: those who want to be entirely shielded from the database and those who want absolute control. I represent a different school of though: I just want something that works. I will admit to having rarely used the Criteria API, though I have appreciated your article on the subject. I have believed JPQL to be simpler for simple things and native queries to be required for complex things. But I will take some time to reassess the capabilities of the Criteria API, particularly in the coexistence scenario which I believe to be the biggest weakness of JPA. -=- Jerry On Jun 3, 2010, at 4:26 PM, Pinaki Poddar [via OpenJPA] wrote: > Hi Jerry, > I hope I am not hijacking the thread's original topic.... > > The provision to allow function() expression in Criteria API was to > accommodate database functions. Not sure why you qualified its location as "a > rather unexpected place". JPA Expert group roughly spent 30-40% of total > deliberation time during JPA 2.0 on how to add a "type-safe" query mechanics. > Criteria API was the crown jewel of JPA 2.0 and expanding string-based, > fixed-grammar JPQL in whichever way was its raison d'être. > > Of course, by adding a new function() expression only covers a small portion > of what the original poster wished for a JPA provider to accommodate in terms > of datastore functionality. But in so doing, the original poster perhaps > placed an expectation on JPA that is quite contrary to its "philosophy". > > JPA wants the developer (who loves his objects so much) to shield from the > database/foreign key/schema/SQL/triggers... In fact, another similar > specification that did influence JPA in a prominent way were not even > committed to a relational database and postulated object persistence on *any* > datastore. I am not arguing whether such effort to shield the database > details from the application programmer is "good" or "bad" -- but it exists > as a school of thought in technical community -- and JPA primarily addresses > that segment/sentiment. > > However, the opposing school that states - "you can not get anything > meaningful done about persistence, unless you directly control/manipulate the > schema and data, or more precisely, set based data" -- is a significant > voice and emboldened by the long reigning power of SQL. A realistic spec such > as JPA can not see the light of the day without catering to that segment > either. Hence this "design by committee" API where > createNativeQuery(String sql) > coexists with > createQuery(CritriaQuery stronglyTypedQuery) > > Another recent poster in this forum asked : "Can the result of native SQL > query be cached in L2 cache?" > The users want good of both worlds -- a strongly-typed, object-oriented data > as well as power of relational database/SQL -- but a spec that aspires to be > "all things to all people" may end up satisfying none. > In my view, it is better to ask: Is an object-oriented, strongly-typed view > that hides access to underlying data model is right for my application's > need? > And if the answer is yes, then choose JPA. > > But coming back to original question of the poster, I will like to mention > that OpenJPA architecturally makes a clean separation between object > management and database interaction via its StoreManager interface -- a > separation so distinct that OpenJPA kernel does not even depend or assume > that the underlying database is relational or JDBC-aware. Such a decision by > original OpenJPA architects is one of its core strength. In the context of > the original question on this thread, Storemanager is the right place to > explore how to leverage specific database functions within OpenJPA runtime. > > > > > > > > > > > Pinaki > > > View message @ > http://openjpa.208410.n2.nabble.com/JPA-for-portable-database-management-tp5134215p5136808.html > > To start a new topic under OpenJPA Users, email > [email protected] > To unsubscribe from OpenJPA Users, click here. > -- View this message in context: http://openjpa.208410.n2.nabble.com/JPA-for-portable-database-management-tp5134215p5136916.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
