[
https://issues.apache.org/jira/browse/HBASE-13271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368862#comment-14368862
]
Lars George commented on HBASE-13271:
-------------------------------------
Good discussion already, let me chime in: yes, this is about the
autoflush==true case. And yes, this is _only_ using the new API. In that case,
you have either a BufferedMutator or a Table. The latter has put(List<Put>) but
what it does in case of an error is hard to handle since we mix local and
remote errors. The remote errors can be dealt with when catching the exception.
But inserting mutations into the local write buffer and triggering a local
error (put is empty, or some such) will cause the above scenario.
I also like to have a put(List) option, it is handy. So what could be done.
Catching the exception and doing the flush() in the final does not help much,
as it leaves the other Puts uncommitted. Example: you have 5 puts an the third
is empty. You call put(list) and the third triggers the local exception. If we
change to code to have a "finally" clause you commit #1 and #2. But _not_ #5.
The client has to catch the exception, then somehow figure out which mutation
was faulty and where to continue. That is mayhem!
I suggest the following rather, for put(List) disable local checks! What that
means is we send it all mutations to the server and get a list back of those
that have failed, while the others all went through. This is assuming that the
majority of API users will have some sense to created proper put instances.
And that is what batch() apparently does, ie. no local checks. But the only
version that is approved is {{batch(final List<? extends Row> actions, final
Object[] results)}} which needs to be translated into what put(List) is
supposed to do. How would we return the list of results or errors for that call?
BTW, this also applies to BufferedMutation.mutate(List<Mutation>). You still
need to figure out what went wrong client side, which will lead to cumbersome,
reinvented boilerplate code at many API users trying to handle lists of
mutations sensibly.
As for
bq. Wondering if BufferedMutaror should have a method to retrive the number of
mutations in buffer (writeAsyncBuffer.size() in current impl)?
I like the idea of having ways to figure out the status of the local buffer.
Right now it is very tightly guarded.
> Table#puts(List<Put>) operation is indeterminate; remove!
> ---------------------------------------------------------
>
> Key: HBASE-13271
> URL: https://issues.apache.org/jira/browse/HBASE-13271
> Project: HBase
> Issue Type: Improvement
> Components: API
> Affects Versions: 1.0.0
> Reporter: stack
>
> Another API issue found by [~larsgeorge]:
> "Table.put(List<Put) is questionable after the API change."
> {code}
> [Mar-17 9:21 AM] Lars George: Table.put(List<Put>) is weird since you cannot
> flush partial lists
> [Mar-17 9:21 AM] Lars George: Say out of 5 the third is broken, then the
> put() call returns with a local exception (say empty Put) and then you have 2
> that are in the buffer
> [Mar-17 9:21 AM] Lars George: but how to you force commit them?
> [Mar-17 9:22 AM] Lars George: In the past you would call flushCache(), but
> that is "gone" now
> [Mar-17 9:22 AM] Lars George: and flush() is not available on a Table
> [Mar-17 9:22 AM] Lars George: And you cannot access the underlying
> BufferedMutation neither
> [Mar-17 9:23 AM] Lars George: You can *only* add more Puts if you can, or
> call close()
> [Mar-17 9:23 AM] Lars George: that is just weird to explain
> {code}
> So, Table needs to get flush back or we deprecate this method or it flushes
> immediately and does not return until complete in the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
