[
https://issues.apache.org/jira/browse/PHOENIX-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626170#comment-14626170
]
ramkrishna.s.vasudevan commented on PHOENIX-2067:
-------------------------------------------------
Went through the patch, on a high level
->We will rewrite the array bytes to use the new seperator byte if it is of
type DESC.
-> for the array_cat - if the existing array to which we will append a new
array is of the old type we will coerce it to use the new sepeartor and the new
array that we add should automatically use the new seperator (if the overall
sort order is DESC) right?
->same with the prepend and append.
But one question regarding the other operations where we try to use the
SEPERATOR_BYTE to find if we have reached the end of the array - in all such
places we should not blindly check with SEPERTOR_BYTE right - instead try to
decide it based on the order of the current byte[]?
> Sort order incorrect for variable length DESC columns
> -----------------------------------------------------
>
> Key: PHOENIX-2067
> URL: https://issues.apache.org/jira/browse/PHOENIX-2067
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.4.0
> Environment: HBase 0.98.6-cdh5.3.0
> jdk1.7.0_67 x64
> CentOS release 6.4 (2.6.32-358.el6.x86_64)
> Reporter: Mykola Komarnytskyy
> Assignee: James Taylor
> Attachments: PHOENIX-2067_array_addendum.patch,
> PHOENIX-2067_array_addendum_v2.patch, PHOENIX-2067_v1.patch,
> PHOENIX-2067_v2.patch, PHOENIX-2067_v3.patch
>
>
> Steps to reproduce:
> 1. Create a table:
> CREATE TABLE mytable (id BIGINT not null PRIMARY KEY, timestamp BIGINT,
> log_message varchar) IMMUTABLE_ROWS=true, SALT_BUCKETS=16;
> 2. Create two indexes:
> CREATE INDEX mytable_index_search ON mytable(timestamp,id) INCLUDE
> (log_message) SALT_BUCKETS=16;
> CREATE INDEX mytable_index_search_desc ON mytable(timestamp DESC,id DESC)
> INCLUDE (log_message) SALT_BUCKETS=16;
> 3. Upsert values:
> UPSERT INTO mytable VALUES(1, 1434983826018, 'message1');
> UPSERT INTO mytable VALUES(2, 1434983826100, 'message2');
> UPSERT INTO mytable VALUES(3, 1434983826101, 'message3');
> UPSERT INTO mytable VALUES(4, 1434983826202, 'message4');
> 4. Sort DESC by timestamp:
> select timestamp,id,log_message from mytable ORDER BY timestamp DESC;
> Failure: data is sorted incorrectly. In case when we have two longs which
> are different only by last two digits (e.g. 1434983826155, 1434983826100)
> and one of the long ends with '00' we receive incorrect order.
> Sorting result:
> 1434983826202
> 1434983826100
> 1434983826101
> 1434983826018
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
