Technically I do not think there are any blocker issues for us to support mutation other than put and delete, as finally we will call table.batch or asyncTable.batch.
But the actual problem here is the return value of the BufferedMutator methods. They just return void, so there is no way for us to get the response of increment and append requests. And the design of BufferedMutator is to make it asynchronous, then there is no way for us to get the responses for the request in the return value, as it will make the method synchronous... For me, I prefer we just deprecated BufferedMutator, and use AsyncBufferMutator directly as we can get the response from the returned CompletableFuture while still keeping the method asynchronous. There is still a problem that we returns the CompletableFuture<Void> so users still can not get the response of increment and append, we need to change the type parameter. Thanks. 何良均 <[email protected]> 于2022年9月16日周五 09:19写道： > > Hey team: > When I read the BufferedMutator#mutate related code, this part of the code > confused me. > > At present, BufferedMutator#mutate only remind the user in the comment that > it only supports Put/Delete, but it is not checked in the code > implementation, and we know that the BufferedMutator is a delegation of > AsyncBufferedMutator. > > After in-depth analysis, although BufferedMutator is a delegation of > AsyncBufferedMutator, BufferedMutatorOverAsyncBufferedMutator#mutate does not > directly call AsyncBufferedMutator#mutate, instead > AsyncBufferedMutatorImpl#mutate(List) is called. > > However, AsyncBufferedMutatorImpl#mutate(List) is a public api, and there is > no description of the mutate type restriction in the comments. > > Besides, AsyncBufferedMutatorImpl#mutate(List) will call the > AsyncTable#batch(List) method, which supports the mutation types including > Get, Put, Delete, Increment, Append, and RowMutations. > > > The logic of this part is really a bit confusing. > > Can we discuss and optimize this part of the code? > > > Thanks.
