Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Tue, 3 Oct 2017 11:50:00 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13106469.1506960872000.259864.1507031400803@Atlassian.JIRA>
In-Reply-To: <JIRA.13106469.1506960872000@Atlassian.JIRA>
References: <JIRA.13106469.1506960872000@Atlassian.JIRA> <JIRA.13106469.1506960872654@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-4265) NPE when hinting index on table
 with ROW_TIMESTAMP
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 03 Oct 2017 11:50:06 -0000


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

Hadoop QA commented on PHOENIX-4265:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12890126/PHOENIX-4265_v1.patch
  against master branch at commit aaa41a33d025ad6daa832fe8b42fc235e7154648.
  ATTACHMENT ID: 12890126

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified tests.
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number of release audit warnings.

    {color:red}-1 lineLengths{color}.  The patch introduces the following lines longer than 100:
    +                    + " (k1 TIMESTAMP not null, k2 bigint not null, v bigint, constraint pk primary key (k1 row_timestamp, k2)) SALT_BUCKETS = 9");
+        long low = lowerUnbound ? -1 : codec.decodeLong(lowestKeyRange.getLowerRange(), 0, SortOrder.DESC);
+        long high = upperUnbound ? -1 : codec.decodeLong(highestKeyRange.getUpperRange(), 0, SortOrder.DESC);

    {color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1511//testReport/
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1511//console

This message is automatically generated.

> NPE when hinting index on table with ROW_TIMESTAMP
> --------------------------------------------------
>
>                 Key: PHOENIX-4265
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4265
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: James Taylor
>            Assignee: Samarth Jain
>         Attachments: PHOENIX-4265_v1.patch
>
>
> See email discussion here: https://lists.apache.org/thread.html/d87a508e5b4e2fc6b7110d861b71209d2385adaecd0152b790ee00e9@%3Cuser.phoenix.apache.org%3E
> I'm not able to repro with this unit test:
> {code}
>     @Test
>     public void testIndexHintOnTableWithRowTimestamp() throws Exception {
>         Connection conn = DriverManager.getConnection(getUrl());
>         try {
>             conn.createStatement().execute("CREATE IMMUTABLE TABLE t1 (k1 TIMESTAMP not null, k2 bigint not null, v bigint, constraint pk primary key (k1 row_timestamp,k2 ))");
>             conn.createStatement().execute("CREATE INDEX idx ON t1 (v)");
>             conn.createStatement().execute("SELECT /*+ INDEX(T1 IDX) */ K1,K2,V FROM t1 WHERE v = 5");
>         } finally {
>             conn.close();
>         }
>     }
> {code}
> FYI, due to the inability to keep an index in sync when there's a ROW_TIMESTAMP column, as of 4.12 we're disallowing the creation of mutable secondary indexes when a table has a ROW_TIMESTAMP column. Usually, since the timestamp is part of the row key, the data table can be declared IMMUTABLE. In this case, the index would still be allowed.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)