[ 
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-880:
------------------------

         Fix Version/s:     (was: 0.19.0)
                        0.20.0
    Remaining Estimate: 240h
     Original Estimate: 240h

Moving to 0.20.0.  Too much work to complete in time for 0.19.0 release.  
Estimate 2 weeks of work, 10d.

{code}
20:19 < St^Ack> ...new API implies new functionality -- don't know how to have 
it fail gracefully without it
20:19 < St^Ack> If we're to add in deprecated, then things like shell and MR 
need to be moved to new stuff
20:20 < St^Ack> Need to handle multiple Cells rather than the presumed one 
everywhere.  Need to do unit tests for new API.
20:20 < St^Ack> Need to retrofit gets, deletes, puts, then their family 
versions, all of a row... then do same for scanners.
20:20 < St^Ack> Make sure works with filters
...
20:21 < St^Ack> Then there is thrift and REST; could punt on these I suppose 
leaving them with deprecated API
{code}

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

Reply via email to