openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar (JIRA)" <j...@apache.org>
Subject [jira] Created: (OPENJPA-1180) Query Parameter processing in JPA 2.0
Date Fri, 17 Jul 2009 15:54:14 GMT
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, kernel, query
            Reporter: Pinaki Poddar
            Assignee: Pinaki Poddar


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.


Mime
View raw message