Hive
  1. Hive
  2. HIVE-5839

BytesRefArrayWritable compareTo violates contract

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.11.0, 0.12.0
    • Fix Version/s: 0.13.0
    • Labels:
      None

      Description

      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.

      1. HIVE-5839.patch
        0.8 kB
        Xuefu Zhang
      2. HIVE-5839.patch
        0.8 kB
        Xuefu Zhang
      3. HIVE-5839.1.patch
        5 kB
        Xuefu Zhang
      4. HIVE-5839.2.patch
        3 kB
        Xuefu Zhang

        Issue Links

          Activity

          Ian Robertson created issue -
          Ian Robertson made changes -
          Field Original Value New Value
          Description 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.
          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.
          Ian Robertson made changes -
          Description 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.
          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.
          Xuefu Zhang made changes -
          Assignee Xuefu Zhang [ xuefuz ]
          Xuefu Zhang made changes -
          Attachment HIVE-5839.patch [ 12614469 ]
          Xuefu Zhang made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Affects Version/s 0.12.0 [ 12324312 ]
          Xuefu Zhang made changes -
          Attachment HIVE-5839.patch [ 12615394 ]
          Xuefu Zhang made changes -
          Attachment HIVE-5839.1.patch [ 12615447 ]
          Xuefu Zhang made changes -
          Remote Link This issue links to "https://reviews.apache.org/r/15820/ (Web Link)" [ 13409 ]
          Xuefu Zhang made changes -
          Attachment HIVE-5839.2.patch [ 12615615 ]
          Navis made changes -
          Status Patch Available [ 10002 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ashutosh Chauhan made changes -
          Fix Version/s 0.13.0 [ 12324986 ]

            People

            • Assignee:
              Xuefu Zhang
              Reporter:
              Ian Robertson
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development