[jira] [Comment Edited] (PHOENIX-2525) Views on transactional tables return no rows

["James Taylor (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069381#comment-15069381 ] 

James Taylor edited comment on PHOENIX-2525 at 12/23/15 3:54 PM:
-----------------------------------------------------------------

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 are running in a single transaction and this is causing a problem, then here are some options:
- set auto commit to true for stats tests, or
- put a commit or rollback in TestUtil.getSplits() and/or TestUtil.analyzeTable()
I think it's important that we're consistent, though, as if we just change this in one single test, it might come back to haunt us. 


was (Author: jamestaylor):
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)