[
https://issues.apache.org/jira/browse/OPENJPA-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pinaki Poddar updated OPENJPA-1180:
-----------------------------------
Component/s: (was: kernel)
Affects Version/s: 2.0.0
Fix Version/s: 2.0.0
> Query Parameter processing in JPA 2.0
> -------------------------------------
>
> Key: OPENJPA-1180
> URL: https://issues.apache.org/jira/browse/OPENJPA-1180
> Project: OpenJPA
> Issue Type: Improvement
> Components: jpa, query
> Affects Versions: 2.0.0
> Reporter: Pinaki Poddar
> Assignee: Pinaki Poddar
> Fix For: 2.0.0
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> JPA 2.0 has defined new APIs for Query parameter processing as well as new
> Parameter<T> and ParameterExpression<T> interface.
> OpenJPA, so far, did not abstract or distinguish query parameters with an
> explicit type definition, and only maintained parameter values in Map or
> array.
> To support JPA 2.0, parameter processing in OpenJPA will undergo following
> changes (which may impact other parts of the code)
> This task will
> a) introduce an explicit QueryParameter interface
> b) provide implementation of the same for query and CriteriaQuery.
> Having an explicit Parameter instance moves the value of the parameter as an
> attribute of the parameter itself and hence the Map<key,value> that a query
> maintained for holding the parameters will now change from Map<String,Object>
> to Map<String,QueryParameter>. To make the callers oblivious of this data
> structural change (as they expect to receive a Map<String,Object> where
> values are Parameter values rather than the Parameter instances themselves),
> new methods will appear in facade QueryImpl.
> CriteriaQuery poses another aspect to query parameter processing. The
> parameters used in CriteriaQuery is modeled as Expression and created by
> QueryBuilder factory. However, the parameters used in a CriteriaQuery c must
> be registered to the executable Query instance q, because the parameter
> values can only be set via methods on q. This registration requires that the
> expression tree of c be walked to detect all its parameters when q is
> constructed of c. This aspect requires a change in the flow of control in the
> initial architecture of CriteriaQuery implementation.
> Care must be taken to ensure that the CriteriaQuery expression tree is not
> walked twice (once merely to detect the parameters and once to form the
> executable query expression for the data store).
> Also parameters of CriteriaQuery *may not* be explicitly named (positional
> parameters are not permitted by spec for CriteriaQuery anyway). The unnamed
> parameter requires the implementation to auto-assign a name to the parameter
> because the maps that contain these parameters require a non-null key.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
