[
https://issues.apache.org/jira/browse/HBASE-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207109#comment-13207109
]
Lars Hofhansl commented on HBASE-3584:
--------------------------------------
@Stack and Ted: Yes to both.
The core problem is that FB has production code out there that uses RowMutation
and that at the same time that code contribution should be in trunk.
So it seems that either:
# We accept that patch into trunk and rename RowMutation, and deprecate the new
RowMutation, etc.
# Do not accept the code. Then FB can either change their code or not
contribute that patch.
I'd rather have #1.
@Kannan: Do you think you can ever change that code on your side? If, yes, we
can either wait for that to happen, or depreate your RowMutation from the
start, and then remove it when you made the production change.
> Allow atomic put/delete in one call
> -----------------------------------
>
> Key: HBASE-3584
> URL: https://issues.apache.org/jira/browse/HBASE-3584
> Project: HBase
> Issue Type: New Feature
> Components: client, coprocessors, regionserver
> Reporter: ryan rawson
> Assignee: Lars Hofhansl
> Fix For: 0.94.0
>
> Attachments: 3584-final.txt, 3584-v1.txt, 3584-v3.txt
>
>
> Right now we have the following calls:
> put(Put)
> delete(Delete)
> increment(Increments)
> But we cannot combine all of the above in a single call, complete with a
> single row lock. It would be nice to do that.
> It would also allow us to do a CAS where we could do a put/increment if the
> check succeeded.
> -----
> Amendment:
> Since Increment does not currently support MVCC it cannot be included in an
> atomic operation.
> So this for Put and Delete only.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
