You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Erik Holstad (JIRA)" <ji...@apache.org> on 2009/08/07 00:32:14 UTC

[jira] Commented: (HBASE-1751) Server vs. Client-side KeyValue

    [ https://issues.apache.org/jira/browse/HBASE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740285#action_12740285 ] 

Erik Holstad commented on HBASE-1751:
-------------------------------------

I regards to making KeyValue comparable, this was to integrate nicely with Cascading. I talked to Chris about this and proposed that the Cascading Tuple would take an Object and a Comparator, so that any object could be put in there without making them all comparable. According to Chris this seems to be happening and if it does we don't need it to be comparable any longer.

Will know more on Saturday.

> 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.