hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Holstad (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-880) Improve the current client API by creating new container classes
Date Sat, 31 Jan 2009 19:11:59 GMT

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

Erik Holstad commented on HBASE-880:
------------------------------------

Hi Andrew!
Yes there are 2 issues like you said and we, me and Jonathan, looked at the code for the filters
in the scanner
and it seems like the filter that we need could be constructed by using a state in that filter,
for getRow(). If the same
filter is to be used for the scanner the last row has to be kept in the filter too, so that
it is only checked ones.
But it seems like filter issues can be solved on our side as long as we have the getRow()
that takes a filter.

> Improve the current client API by creating new container classes
> ----------------------------------------------------------------
>
>                 Key: HBASE-880
>                 URL: https://issues.apache.org/jira/browse/HBASE-880
>             Project: Hadoop HBase
>          Issue Type: Improvement
>          Components: client
>            Reporter: Jean-Daniel Cryans
>            Assignee: Jean-Daniel Cryans
>             Fix For: 0.20.0
>
>         Attachments: 880.patch, 880proposal4plus-v2.patch, 880proposal4plus.patch, 880proposal5-v2.patch,
880proposal5-v2.png, 880proposal5.patch, 880proposal5.png, hbase-880-patch.jpg, hbase-880-proposal4.patch,
hbase-880-v1.patch, hbase-880-v2.patch, hbase_client_classes.png, NewCilentAPIProposoal4.gif,
proposal2.jpg, proposed.jpg
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> The current API does not scale very well. For each new feature, we have to add many methods
to take care of all the overloads. Also, the need to batch row operations (gets, inserts,
deletes) implies that we have to manage some "entities" like we are able to do with BatchUpdate
but not with the other operations. The RowLock should be an attribute of such an entity.
> The scope of this jira is only to replace current API with another feature-compatible
one, other methods will be added in other issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message