[jira] Commented: (OPENJPA-703) Cache ResultObjectProvider data to improve query performance

["Pinaki Poddar (JIRA)" <ji...@apache.org>]

    [ 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.