hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9496) make sure HBase APIs are compatible between 0.94 and 0.96
Date Tue, 10 Sep 2013 22:45:51 GMT

    [ 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:
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
3:36 inside the method that is.
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 ...
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.
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.).
3:38 sershe:  I think this is true for things that have KeyValue in the return type.
3:38 hmm?
3:38 for thing that used to take a single KeyValue Cell is ok
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.
3:39 "other than those that take Cell-types params is the way to go"
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.
3:39 Result ctor is probably the worst, the java way for this is to add a boolean dummy param
but that's ugly...
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.
3:40 that is true
3:40 let me file a jira and we can figure it out
3:41 I'm working with some of our hive guys to see how much of the hbase api we broke for
3:41 there is the getFailyCellMap thing, an HConstant.META_TABLE_NAME that got replaced with
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).
3:43 I saw it in some other projects iirc
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.
> 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

View raw message