[
https://issues.apache.org/jira/browse/HBASE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757553#action_12757553
]
Erik Holstad commented on HBASE-1845:
-------------------------------------
@Stack
Deprecating sounds good to me, will have the old calls use this new one behind
the scenes if we decide to use this.
I would say that checking if the list is sorted will probably go pretty fast,
usually, since it breaks at the first occurrence of an unsorted element, but
I'm open to remove it, would like to do
some timing test to see if it is worth it or not before making the decision.
Will add the check for one element
Like the name Results, but not really liking Rows but it is not a big deal to
me either. Think that batch is kinda ok.
The reason that Row needs to be writable is the same as for Filter. Will make
it WritableComparable, so that will lead to Gets, Puts and Deletes just
implement Row. Not sure that this is good though, to hide those inside Row?
As the code is written now, you can mix and match all of the types into one
batch, but I need to do more testing on this and we might need to extend the
compare code to include something more than row.
Yeah, I guess that it what that means, Not really sure what would be the best
alternative here and if we are looking to make HTable thread safe?
I have done some test for recovery, that are not in the patch, but those
required modifying the actual code, but will try to figure something out so we
can put it in a unit test.
> Discussion issue for multi calls, MultiDelete, MultiGet and MultiPut
> --------------------------------------------------------------------
>
> Key: HBASE-1845
> URL: https://issues.apache.org/jira/browse/HBASE-1845
> Project: Hadoop HBase
> Issue Type: New Feature
> Reporter: Erik Holstad
> Fix For: 0.21.0
>
> Attachments: batch.patch, multi-v1.patch
>
>
> I've started to create a general interface for doing these batch/multi calls
> and would like to get some input and thoughts about how we should handle this
> and what the protocol should
> look like.
> First naive patch, coming soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
