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 this message in context:
http://openjpa.208410.n2.nabble.com/JPA-for-portable-database-management-tp5134215p5136808.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
