[
https://issues.apache.org/jira/browse/HBASE-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002329#comment-13002329
]
stack commented on HBASE-3599:
------------------------------
Good one Greg.
Yeah, we should javadoc assumption that input is sorted.
We used to have this in the Result API:
{code}
/**
* Returns a sorted array of KeyValues in this Result.
* <p>
* Note: Sorting is done in place, so the backing array will be sorted
* after calling this method.
* @return sorted array of KeyValues
*/
public KeyValue[] sorted() {
if (isEmpty()) {
return null;
}
Arrays.sort(kvs, (Comparator<KeyValue>)KeyValue.COMPARATOR);
return kvs;
}
{code}
.. but removed it.
We could put back a sort method for use in the unit test scenario you describe
above?
> Result constructor assumes input is already sorted
> --------------------------------------------------
>
> Key: HBASE-3599
> URL: https://issues.apache.org/jira/browse/HBASE-3599
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.0
> Reporter: Greg Wittel
> Priority: Minor
>
> The Result(List<KeyValue>) and Result(KeyValue[]) constructor assume that the
> input is already sorted (HBASE-3073, HBASE-2753). This works for normal use
> cases, but not for hand constructed Result objects (e.g. unit tests).
> I encountered this when upgrading to 0.90 that some unit tests now failed due
> to this. One fix is to add some documentation on the constructors that says
> the input MUST be sorted. The other would be to explicitly sort the items
> (not so desirable).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
