[
https://issues.apache.org/jira/browse/HBASE-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729950#action_12729950
]
stack commented on HBASE-1622:
------------------------------
@Erik: Going by what you say above, you are making an argument that KV and R
should just be WritableComparables; creating a new class, a KeyValueComparable
by passing in a KV and then giving it to cascading sounds kinda painful. The
only time the Comparable is an issue is internally when we are doing the
catalog table compares -- though nothing to stop a user scaning .META. and
getting the special KVs back. Doing a compareTo on these, they'd be hosed.
Here we don't want to use the KVs internal default comparable but the one that
knows how to deal with .META. keys.
If we have to wait till cascading does new 0.20.0 MR interface, lets punt on
these as you suggest but if we really need these things Comparable, would be
good to make the change before 0.20.0 release.
Do they have to be Comparable? Can we not pass Comparator to use?
> Make KeyValue implement the Comparable interface to make it work with
> Cascading.
> --------------------------------------------------------------------------------
>
> Key: HBASE-1622
> URL: https://issues.apache.org/jira/browse/HBASE-1622
> Project: Hadoop HBase
> Issue Type: New Feature
> Affects Versions: 0.20.0
> Reporter: Erik Holstad
> Assignee: Erik Holstad
> Priority: Minor
> Fix For: 0.20.0
>
> Attachments: 1622-3.patch, HBASE-1622-v1.patch, HBASE-1622-v2.patch
>
>
> As with making Result implement the Comparable interface, this is used for
> making HBase interact tightly with cascading, so that KeyValues can be put
> into Tuples.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
