[jira] [Commented] (HBASE-9496) make sure HBase APIs are compatible between 0.94 and 0.96

["Sergey Shelukhin (JIRA)" <ji...@apache.org>]

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

Sergey Shelukhin commented on HBASE-9496:
-----------------------------------------

>From IRC:
{noformat}
sershe
3:36 k let me file a jira… we talked here with Enis and it seems like having 2 APIs, KV and Cell, for every method other than those that take Cell-types params is the way to go
jmhsieh
3:36 inside the method that is.
sershe
3:36 then in 98 or later we can remove the KV ones
3:37 otherwise everyone will have to make shims for these things to build with 94, or drop 94 support which is not feasible soon
3:37 *for every method that mentions Cells, other than ...
jmhsieh
3:37 That is because the result could be a List<? extends Cell> that doesn't implement KV -- like PrefixTreeCell lets say and we are hosed.
sershe
3:37 i.e. returns Cell, or takes Foo<… Cell …> param
3:37 HarrisonF left the room (quit: Read error: Connection reset by peer).
3:38 jasonbray left the room (quit: Quit: Computer has gone to sleep.).
jmhsieh
3:38 sershe:  I think this is true for things that have KeyValue in the return type.
sershe
3:38 hmm?
jmhsieh
3:38 for thing that used to take a single KeyValue Cell is ok
sershe
3:38 yeah yeah that's what I meant
3:38 HarrisonF [~hfisk@2620:0:1cfe:18:2acf:e9ff:fe17:edb3] entered the room.
3:38 HarrisonF left the room (quit: Changing host).
3:38 HarrisonF [~hfisk@mysql/training/HarrisonF] entered the room.
sershe
3:39 "other than those that take Cell-types params is the way to go"
jmhsieh
3:39 for thigns that take List<Cell> now but used to take List<KeyValue> is where we get hurt -- and maybe alternate methods make more sense here.
3:39 yeah -- I think we are on the same page.
sershe
3:39 Result ctor is probably the worst, the java way for this is to add a boolean dummy param but that's ugly...
jmhsieh
3:40 I'd argue that uses should neer really need to construct Ctor.s
3:40 construct Results that is -- the methods reutrn then them to users.
sershe
3:40 that is true
3:40 let me file a jira and we can figure it out
jmhsieh
3:41 I'm working with some of our hive guys to see how much of the hbase api we broke for them.
3:41 there is the getFailyCellMap thing, an HConstant.META_TABLE_NAME that got replaced with TableNAme.META_TABLE_NAME
3:42 but I don't think we got complaints about the places where List<Cell> was an argument (definitely got it for Cells were in return types though).
sershe
3:43 I saw it in some other projects iirc
jmhsieh
3:43 But then again I've foudn that some of those folks need to complain more about this.  I'm actually really happy this got brough up.
{noformat}
                
> make sure HBase APIs are compatible between 0.94 and 0.96
> ---------------------------------------------------------
>
>                 Key: HBASE-9496
>                 URL: https://issues.apache.org/jira/browse/HBASE-9496
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Sergey Shelukhin
>            Priority: Critical
>
> Follow-up for HBASE-9477.
> Some other methods are now different between 94 and 96 (Result::getColumnLatest, Put::get, anything that takes a collection of Cell, e.g. Result ctor, Mutation::setFamilyMap etc.).
> I am assuming things that accept Cell (Increment::add, Delete::addDeleteMarker) don't need to change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira