Description
JPA 2.0 has introduced specification for strictly-typed dynamic query construction a.k.a Criteria API. The design challenge to support this feature comes from the following
1. how to leverage existing OpenJPA query infrastructure?
2. the type-strictness is supported on the basis of a instantiated meta-model – this is new for OpenJPA query infrastructure. Should we introduce more type-strictness in OpenJPA query infrastructure or not?
The design goals (currently)
1. select current design pattern rather than some arbitrary hack to bridge existing OpenJPA query infrastructure and JPA 2.0 type-strict Criteria. Possibly it is Adapter pattern.
2. Do not change OpenJPA query infrastructure with more type-strictness (it is not type-free after all). Rather inject type information from the artifacts that implement new Criteria API into OpenJPA query artifacts.
The implementation strategy:
1. Prototype the approach first.
2. Solidify a design that can be boiler plated (ok, almost) for numerous supported query expression and clauses. Then delegate construction of these parts.
Attachments
Issue Links
- incorporates
-
OPENJPA-1277 Support JPQL to Criteria Query conversion
- Reopened
-
OPENJPA-1195 Allow datastore function as query expression
- Closed
-
OPENJPA-1198 Query by Example
- Closed
-
OPENJPA-1241 Add support for joining via keys of a Map attribute for Criteria query
- Closed
-
OPENJPA-1265 Support Edit on Criteria Query
- Closed
-
OPENJPA-1267 Support JDBC Escape syntax for temporal types on Criteria Query
- Closed
-
OPENJPA-1276 Support CQL for Criteria Query
- Closed
-
OPENJPA-1278 Define interfaces for OpenJPA specific extension to Criteria Query API
- Closed
-
OPENJPA-1288 Support alias() on Criteria Query API
- Closed
-
OPENJPA-1290 Document Criteria API
- Closed
- is blocked by
-
OPENJPA-1225 Improve query result processing with composite pattern
- Closed
- is part of
-
OPENJPA-1007 OpenJPA 2.0 iteration 6 primary task
- Closed
- relates to
-
OPENJPA-1014 Build weakly-typed Criteria API
- Closed