Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Fri, 7 Aug 2015 18:40:46 +0000 (UTC)
From: "James Taylor (JIRA)" <jira@apache.org>
To: dev@phoenix.incubator.apache.org
Message-ID: <JIRA.12853029.1438972550000.7925.1438972846372@Atlassian.JIRA>
In-Reply-To: <JIRA.12853029.1438972550000@Atlassian.JIRA>
References: <JIRA.12853029.1438972550000@Atlassian.JIRA>
 <JIRA.12853029.1438972550978@arcas>
Subject: [jira] [Updated] (PHOENIX-2171) DOUBLE and FLOAT DESC are stored as
 ASC
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/PHOENIX-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Taylor updated PHOENIX-2171:
----------------------------------
    Attachment: PHOENIX-2171.patch

[~samarthjain] - please review this patch. Good call on writing more tests for PHOENIX-2137, as it turned up this nasty bug. The fix is pretty straight forward, but how to fix data that's already been written incorrectly is another story. Maybe no one has DOUBLE DESC row keys and we should just get a patch out quickly and release note it.

> DOUBLE and FLOAT DESC are stored as ASC
> ---------------------------------------
>
>                 Key: PHOENIX-2171
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2171
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Priority: Critical
>         Attachments: PHOENIX-2171.patch
>
>
> Our PDouble.getCodec().decodeDouble() and PFloat.getCodec().decodeFloat() methods are updating the byte array in-place when the data is DESC which is a big no-no as it essentially corrupts data. The end effect is that data which is attempted to be stored as DESC is stored ASC instead, with the data appearing as being corruprt. Not sure if this is always the case for ingest paths, but a common UPSERT VALUES is impacted:
> {code}
> 0: jdbc:phoenix:localhost> create table dd (k double primary key desc);
> No rows affected (1.356 seconds)
> 0: jdbc:phoenix:localhost> upsert into dd values (1.0);
> 1 row affected (0.054 seconds)
> 0: jdbc:phoenix:localhost> upsert into dd values (2.0);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> select * from dd;
> +------------------------------------------+
> |                    K                     |
> +------------------------------------------+
> | -1.0000000000000004                      |
> | -2.000000000000001                       |
> +------------------------------------------+
> 2 rows selected (0.038 seconds)
> {code}
> Not sure how to fix this in terms of data that has already been written. One potential solution is to switch the column to be ASC instead of DESC (since that's how it is actually stored):
> {code}
> put 'SYSTEM.CATALOG', "\x00\x00DD\x00K", '0:SORT_ORDER', "\x80\x00\x00\x00"
> {code}
> And now the data is interpreted correctly:
> {code}
> 0: jdbc:phoenix:localhost> select * from dd;
> +------------------------------------------+
> |                    K                     |
> +------------------------------------------+
> | 1.0                                      |
> | 2.0                                      |
> +------------------------------------------+
> 2 rows selected (6.157 seconds)
> {code}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)