[
https://issues.apache.org/jira/browse/PHOENIX-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17009303#comment-17009303
]
Hadoop QA commented on PHOENIX-4845:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12990051/PHOENIX-4845-4.x-HBase-1.3.patch
against 4.x-HBase-1.3 branch at commit
7bcc9bc89bbe86eedbf8223d101dadb3cf57cc4c.
ATTACHMENT ID: 12990051
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 13 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the master's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ static final String SIMPLE_DDL = "CREATE TABLE %s (t_id VARCHAR NOT
NULL,\n" + "k1 INTEGER NOT NULL,\n"
+ static final String DATA_DDL = "CREATE TABLE %s (k1 TINYINT NOT NULL,\n" +
"k2 TINYINT NOT NULL,\n"
+ + "k3 TINYINT NOT NULL,\n" + "v1 INTEGER,\n" + "CONSTRAINT pk
PRIMARY KEY (k1, k2, k3)) ";
+ String createIndex = "CREATE INDEX IF NOT EXISTS " + indexName + "
ON " + tableName + " (k2 DESC,k1)";
+ String createDataIndex = "CREATE INDEX IF NOT EXISTS " +
dataIndexName + " ON " + dataTableName + " (k2 DESC,k1)";
+ String failureSql = String.format("SELECT t_id, k1, k2 FROM %s OFFSET
(t_id, k1, k2)=('a', 'ab', 2)", tableName);
+ String failureSql = String.format("SELECT t_id, k1, k2, v1 FROM %s
ORDER BY v1 OFFSET (t_id, k1, k2)=('a', 1, 2)", tableName);
+ String failureSql = String.format("SELECT t_id, k1, k2 FROM %s ORDER
BY k1 OFFSET (t_id, k1, k2)=('a', 1, 2)", tableName);
+ String failureSql = String.format("SELECT t_id, k1, k2 FROM %s ORDER
BY t_id DESC, k1, k2 OFFSET (k1,k2,k3)=('a', 1, 2)",
+ String failureSql = String.format("SELECT T1.k1,T2.k2 FROM %s AS T1,
%s AS T2 WHERE T1.t_id=T2.t_id OFFSET (k1,k2,k3)=('a', 1, 2)",
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TenantIdTypeIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3237//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3237//artifact/patchprocess/patchReleaseAuditWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3237//console
This message is automatically generated.
> Support using Row Value Constructors in OFFSET clause for paging in tables
> where the sort order of PK columns varies
> --------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-4845
> URL: https://issues.apache.org/jira/browse/PHOENIX-4845
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Thomas D'Silva
> Assignee: Daniel Wong
> Priority: Major
> Labels: DESC, SFDC
> Attachments: PHOENIX-4845-4.x-HBase-1.3.patch, PHOENIX-offset.txt
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> RVCs along with the LIMIT clause are useful for efficiently paging through
> rows (see [http://phoenix.apache.org/paged.html]). This works well if the pk
> columns are sorted ascending, we can always use the > operator to query for
> the next batch of row.
> However if the PK of a table is (A DESC, B DESC) we cannot use the following
> query to page through the data
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> Since the rows are sorted by A desc and then by B descending we need change
> the comparison order
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> If the PK of a table contains columns with mixed sort order for eg (A DESC,
> B) then we cannot use RVC to page through data.
> If we supported using RVCs in the offset clause we could use the offset to
> set the start row of the scan. Clients would not have to have logic to
> determine the comparison operator. This would also support paging through
> data for tables where the PK columns are sorted in mixed order.
> {code:java}
> SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
> {code}
> We would only allow using the offset if the rows are ordered by the sort
> order of the PK columns of and Index or Primary Table.
> Note that there is some care is needed in the use of OFFSET with indexes. If
> the OFFSET is coercible to multiple indexes/base table it could mean very
> different positions based on key. To Handle This the INDEX hint needs to be
> used to specify an index offset for safety.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
