[
https://issues.apache.org/jira/browse/PHOENIX-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688940#comment-16688940
]
Hudson commented on PHOENIX-4841:
---------------------------------
FAILURE: Integrated in Jenkins build Phoenix-4.x-HBase-1.3 #259 (See
[https://builds.apache.org/job/Phoenix-4.x-HBase-1.3/259/])
PHOENIX-4841 staging patch commit. (tdsilva: rev
87e7702966ab7bc0afd52696e453f57ccc28b369)
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryMoreIT.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/expression/ComparisonExpression.java
* (add)
phoenix-core/src/main/java/org/apache/phoenix/expression/rewrite/RowValueConstructorExpressionRewriter.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/compile/WhereOptimizer.java
* (add)
phoenix-core/src/test/java/org/apache/phoenix/expression/rewrite/RowValueConstructorExpressionRewriterTest.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/schema/RowKeySchema.java
> Filters that uses RVC with pk columns where with DESC sort order don't work
> correctly
> -------------------------------------------------------------------------------------
>
> Key: PHOENIX-4841
> URL: https://issues.apache.org/jira/browse/PHOENIX-4841
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.0, 5.1.0
> Reporter: Thomas D'Silva
> Assignee: Daniel Wong
> Priority: Major
> Labels: DESC
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4841-v2.patch, PHOENIX-4841-v3.patch,
> PHOENIX-4841-v4.patch, PHOENIX-4841-v5.patch, PHOENIX-4841-v6.patch,
> PHOENIX-4841.4.x-HBase-1.4.patch, PHOENIX-4841.patch
>
>
> If we filter on pk columns where one of the columns is DESC, we don't get the
> expected results. If the PK columns are of sorted by ASC we get the correct
> results. For eg. the following test fails:
> {code}
> @Test
> public void testRVCWithDescAndAscPK() throws Exception {
> String fullTableName = generateUniqueName();
> // create base table and global view using global connection
> try (Connection conn = DriverManager.getConnection(getUrl())) {
> Statement stmt = conn.createStatement();
> stmt.execute("CREATE TABLE " + fullTableName + "(\n" +
> " A VARCHAR NOT NULL,\n" +
> " B VARCHAR NOT NULL,\n" +
> " C VARCHAR NOT NULL,\n" +
> " CONSTRAINT PK PRIMARY KEY (A, B DESC, C))");
>
> conn.createStatement().execute("UPSERT INTO " + fullTableName + "
> VALUES ('x', 'd', '1')");
> conn.createStatement().execute("UPSERT INTO " + fullTableName + "
> VALUES ('x', 'c', '2')");
> conn.createStatement().execute("UPSERT INTO " + fullTableName + "
> VALUES ('x', 'b', '3')");
> conn.createStatement().execute("UPSERT INTO " + fullTableName + "
> VALUES ('x', 'b', '4')");
> conn.createStatement().execute("UPSERT INTO " + fullTableName + "
> VALUES ('x', 'a', '4')");
> conn.commit();
> }
> // validate that running query using global view gives same results
> try (Connection conn = DriverManager.getConnection(getUrl())) {
> ResultSet rs =
> conn.createStatement().executeQuery(
> "SELECT B, C FROM " + fullTableName + " WHERE (B, C)
> > ('b', '3')");
> assertTrue(rs.next());
> assertEquals("d", rs.getString(1));
> assertEquals("1", rs.getString(2));
> assertTrue(rs.next());
> assertEquals("c", rs.getString(1));
> assertEquals("2", rs.getString(2));
> assertTrue(rs.next());
> assertEquals("b", rs.getString(1));
> assertEquals("4", rs.getString(2));
> assertFalse(rs.next());
> }
> }
> {code}
> The comparison expression for the above query is
> {code}
> (PK[-1], PK[-1]) > (TO_VARCHAR('b'), '3')
> {code}
> When the first row is evaluated the lhs bytes is:
> {code}
> [-101, -1, 49]
> {code}
> and rhs bytes:
> {code}
> [-99, -1, 51]
> {code}
> We invert the bytes of the B column but since the greater than comparison
> operator usedthe row is filtered out (even though it should be returned).
> [~jamestaylor]
> When a column is DESC order do we need to rewrite the comparison expression?
> Instead of
> {code}
> WHERE (B, C) > ('b', '3')
> {code}
> we need something like
> {code}
> WHERE B<~'b' OR (B=~'b' AND C>'3')
> {code}
> Is there a better way to handle this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
