[
https://issues.apache.org/jira/browse/DERBY-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670598#action_12670598
]
Mamta A. Satoor commented on DERBY-4048:
----------------------------------------
derbyall ran fine with jdk15 on my machine. Hoping someone can try my patch and
run *junit tests* to see if everything runs fine on their machine.
> Update Statistics code in AlterTableConstantAction should use execute
> transaction rather than compile transaction
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4048
> URL: https://issues.apache.org/jira/browse/DERBY-4048
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.5.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mamta A. Satoor
> Attachments: DERBY4048_useExecuteTran_diff.txt
>
>
> DERBY-269 provided a new stored procedure SYSCS_UTIL.SYSCS_UPDATE_STATISTICS
> to update the statistics. The code to do the work was added in
> AlterTableConstantAction and the name of new method in that class is
> updateStatistics(Activation activation). This code was copied from an
> existing unused class execute/UpdateStatisticsConstantAction.java(that unused
> class has been removed from Derby code).
> The copied code in AlterTableConstantAction:updateStatistics gets compile
> transaction as shown below to do the work of updating the statistics.
> TransactionController tc = lcc.getTransactionCompile();
> The javadoc for LangaugeConnectionContext for getTransactionCompile says
> following
> /**
> Get the transaction controller to use with this language
> connection
> context at compile time.
> */
> TransactionController getTransactionCompile();
> I think we should be using TransactionController tc =
> lcc.getTransactionExecute() to do the work since we are not in the compile
> phase. The rest of the code in AlterTableConstantAction uses
> lcc.getTransactionExecute to get the transaction controller.
> I will make the changes in AlterTableConstantAction.updateStatistics to use
> getTransactionExecute and will run the existing tests to make sure nothing
> breaks.
> I ran into this issue of getTransactionExecute vs getTransactionCompile while
> working on DERBY-3788 (provide a zero-admin way of updating the statistics).
> While trying to run the statistics inline duirn the compile phase of a SELECT
> query, I ran into exception that statistics can't be updated because we are
> in read-only mode. But if I change the AlterTableConstantAction to use
> getTransactionExecute, then I do not run into the read-only mode exception.
> Please let me know if anyone has any comments on this. I will run the
> existing tests and if no failures, then I will go ahead and commit the change
> of using getTransactionExecute rather than getTransactionCompile in
> AlterTableConstantAction:updateStatistics
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
