[
https://issues.apache.org/jira/browse/PHOENIX-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069381#comment-15069381
]
James Taylor commented on PHOENIX-2525:
---------------------------------------
Did you try having updateStatisticsInternal() use LATEST_TIMESTAMP regardless
of the timestamp at which the table was resolved? Do you think that approach
would make sense? What's the code path through BaseQueryPlan.iterators() here
in this case?
{code}
if (!table.isTransactional()) {
// Get the time range of row_timestamp column
TimeRange rowTimestampRange =
context.getScanRanges().getRowTimestampRange();
// Get the already existing time range on the scan.
TimeRange scanTimeRange = scan.getTimeRange();
Long scn = connection.getSCN();
if (scn == null) {
// If we haven't resolved the time at the beginning of
compilation, don't
// force the lookup on the server, but use
HConstants.LATEST_TIMESTAMP instead.
scn = tableRef.getTimeStamp();
if (scn == QueryConstants.UNSET_TIMESTAMP) {
scn = HConstants.LATEST_TIMESTAMP;
}
}
{code}
The problem with calling commit or rollback before UPDATE STATISTICS is it has
the unintended side effect of committing or rolling back an in progress
transaction. I think it's ok if the stats aren't picked up until the next
transaction, so the removeTable() shouldn't be necessary. If the tests need to
do a commit to pass, then put a commit or rollback in TestUtil.getSplits()
and/or TestUtil.analyzeTable() so that it's consistent across all the test
rather than in one single test (as otherwise it'll come back to haunt us).
> Views on transactional tables return no rows
> --------------------------------------------
>
> Key: PHOENIX-2525
> URL: https://issues.apache.org/jira/browse/PHOENIX-2525
> Project: Phoenix
> Issue Type: Bug
> Reporter: Mujtaba Chohan
> Assignee: Thomas D'Silva
> Attachments: PHOENIX-2525-v2.patch, PHOENIX-2525-v3.patch,
> PHOENIX-2525-wip.patch, PHOENIX-2525.patch
>
>
> Aggregate or non-aggregate queries do not return any rows to the client for
> views created over transactional table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
