[
https://issues.apache.org/jira/browse/HBASE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635866#action_12635866
]
Jim Kellerman commented on HBASE-880:
-------------------------------------
@Stack
{quote}
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.
{quote}
It should be easy enough to add. Does it make sense for all of get/put/delete?
{quote}
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').
{quote}
Yes, you can do both puts and deletes in one operation.
{quote}
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?)
{quote}
I kind of struggled with this one, and it ended up the way it did since you
asked that get return Cell[] instead of RowResult. I would
prefer that we drop GetOperation and rename RowGetOperation to GetOperation, if
you think that it's ok for a single get to return
SortedMap<byte[], Cell> instead of Cell[], it's an easy change and enables
folding AbstractGetOperation into the new GetOperation
as well. I can certainly draw it up and we can see which we like better.
> 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.
