[
https://issues.apache.org/jira/browse/OPENJPA-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669012#action_12669012
]
Pinaki Poddar commented on OPENJPA-703:
---------------------------------------
This commit introduces few changes that may impact other developers.
1. The identity type for a Query Parameter expression has changed from String
to Object. This changes are reflected in
/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/kernel/exps/Parameter.java
and all its subclasses.
2. Query parsing preserves the runtime type of the parameter keys. The same
parameter keys must be used as the key of the returned map from the following
method of StoreQuery.Executor
public LinkedMap getParameterTypes(StoreQuery q);
This impact is shown in JPQLExpressionBuilder.getParameters().
Both the above changes to preserve the actual type of the parameter key
(numeric or String) is important to identify them later when a query is
executed with a new set of user parameter values.
3. As QueryExpression Tree is walked and each node contributes to fill in the
SQLBuffer, the user defined parameters must distinguish themselves from any
other SQL parameters being inserted in SQLBuffer. This distinction is critical
for reparameterizing the cached SQL with a new set of user parameter values
while keeping the internal parameter values intact. This aspect add a new
overloaded SQLBuffer.appendValue(Object, Column, Parameter) method.
> Cache ResultObjectProvider data to improve query performance
> ------------------------------------------------------------
>
> Key: OPENJPA-703
> URL: https://issues.apache.org/jira/browse/OPENJPA-703
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Ron Pressler
>
> Profiling indicated that JDBCStoreQuery.populateSelect consumes a significant
> amount of CPU, and is executed every time a query is run. While, in fact, the
> actual PreparedStatement is created and run only in QueryImpl.toResult. It
> seems like the returned ResultObjectProvider from JDBCStoreQuery.executeQuery
> can be at least partially cached, or even cached in its entirety (provided
> care is taken with the context parameters).
> It seems like such an improvement would significantly improve query
> performance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
