[
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635860#action_12635860
]
stack commented on HBASE-880:
-----------------------------
bq. Neither the current API nor the 880 patch supports different timestamps for
update, get(column) or getRow. Are you proposing we add this?
Doğacan Güney did over in HBASE-899. There you were thinking it would not be
too difficult to add? Seems reasonable to me: i.e. timestamp does not below
with row but rather with column specification.
bg. Neither trunk nor 880 patch permit that...
I see now how my comment confused things by grouping get with put and delete.
Pardon me. What I meant was that when updating, you should be able to mix put
and delete operations on the one row and asking if this redesign allowed that.
Seems like I can make RowMutation object and do deletes and puts against the
one row (You can't do get and updates in the one operation. That 'normal').
Regards the proposal, if I want to get values for many columns -- not all
columns on a row but some subset -- how do I do it? I use a RowGetOperation
instead of a GetOperation? We should have better naming, don't you think?
Should we drop the GetOperation and instead rename current RowGetOperation as
GetOperation and use it everywhere? (If we do this, we won't be able to do
hbase-899 as written?)
bq. Note that I removed the deprecated methods from HTable so we could see what
the eventual API looks like without all the other clutter.
+1. Helps with visualization.
> 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.19.0
>
> Attachments: hbase-880-patch.jpg, hbase-880-v1.patch,
> hbase-880-v2.patch, hbase_client_classes.png, proposed.jpg
>
>
> 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.
