[
https://issues.apache.org/jira/browse/HIVE-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830598#comment-13830598
]
Hive QA commented on HIVE-5839:
-------------------------------
{color:green}Overall{color}: +1 all checks pass
Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12615447/HIVE-5839.1.patch
{color:green}SUCCESS:{color} +1 4681 tests passed
Test results:
http://bigtop01.cloudera.org:8080/job/PreCommit-HIVE-Build/411/testReport
Console output:
http://bigtop01.cloudera.org:8080/job/PreCommit-HIVE-Build/411/console
Messages:
{noformat}
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
{noformat}
This message is automatically generated.
ATTACHMENT ID: 12615447
> BytesRefArrayWritable compareTo violates contract
> -------------------------------------------------
>
> Key: HIVE-5839
> URL: https://issues.apache.org/jira/browse/HIVE-5839
> Project: Hive
> Issue Type: Bug
> Components: Serializers/Deserializers
> Affects Versions: 0.11.0, 0.12.0
> Reporter: Ian Robertson
> Assignee: Xuefu Zhang
> Attachments: HIVE-5839.1.patch, HIVE-5839.patch, HIVE-5839.patch
>
>
> BytesRefArrayWritable's compareTo violates the compareTo contract from
> java.lang.Object. Specifically:
> * The implementor must ensure sgn(x.compareTo( y )) == -sgn(y.compareTo( x ))
> for all x and y.
> The compareTo implementation on BytesRefArrayWritable does a proper
> comparison of the sizes of the two instances. However, if the sizes are the
> same, it proceeds to do a check if both array's have the same constant. If
> not, it returns 1. This means that if x and y are two BytesRefArrayWritable
> instances with the same size, but different contents, then x.compareTo( y )
> == 1 and y.compareTo( x ) == 1.
> Additionally, the comparison of contents is order agnostic. This seems wrong,
> since order of entries should matter. It is also very inefficient, running at
> O(n^2), where n is the number of entries.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
