After talking to Chris this weekend, it looks like Cascading is going to take the good approach of putting objects in its tuples and you can add a custom comparator when and if you need to do sorting. That removes all the needs for having your classes implement comparable for us.
On Thu, Aug 6, 2009 at 7:53 PM, stack (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/HBASE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740375#action_12740375] > > stack commented on HBASE-1751: > ------------------------------ > > @Erik Thanks. Good to hear. Then, its just case of javadoc. We should > make it digestible for client-side users rather than cognescenti, the > server-writers. Then I'd close this issue. > > > Server vs. Client-side KeyValue > > ------------------------------- > > > > Key: HBASE-1751 > > URL: https://issues.apache.org/jira/browse/HBASE-1751 > > Project: Hadoop HBase > > Issue Type: Improvement > > Reporter: stack > > > > Do we need a server-side and client-side version of KeyValue? > > One of the lads here was trying to write client-side code and got put off > by javadoc that said "do not use this" (he wanted to getValue and didn't > know ahead of time what columns the Result contained). This would seem to > say we need javadoc for server-side and then different javadoc for > client-side. > > Holstad wants KV to be comparable. We can't make KV comparable because > at least on server-side, comparator to use changes with context. If there > was a server-side KV, then we could make that comparable and leave the > server-side KV alone. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
