[ https://issues.apache.org/jira/browse/OPENJPA-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Donald Woods updated OPENJPA-1180:
----------------------------------

    Affects Version/s:     (was: 2.0.0)
        Fix Version/s:     (was: 2.0.0-M4)
                           (was: 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
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 2.0.0-M3
>
>   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.