Will Berkeley commented on KUDU-1563:

I was thinking a new operation.

1. It's cleaner to handle as a different operation type.
2. It has different (error) semantics.
3. Easier to keep track of in code (both client and server).
4. Easier to keep metrics on.
5. I'm not sure there's a notion of a flag on a single operation in a batch-- 
that would have to be invented just for this.

> INSERT IGNORE operation type
> ----------------------------
>                 Key: KUDU-1563
>                 URL: https://issues.apache.org/jira/browse/KUDU-1563
>             Project: Kudu
>          Issue Type: New Feature
>            Reporter: Dan Burkert
>            Assignee: Brock Noland
>              Labels: newbie
> The Java client currently has an [option to ignore duplicate row key errors| 
> https://kudu.apache.org/apidocs/org/kududb/client/AsyncKuduSession.html#setIgnoreAllDuplicateRows-boolean-],
>  which is implemented by filtering the errors on the client side.  If we are 
> going to continue to support this feature (and the consensus seems to be that 
> we probably should), we should promote it to a first class operation type 
> that is handled on the server side.  This would have a modest perf. 
> improvement since less errors are returned, and it would allow INSERT IGNORE 
> ops to be mixed in the same batch as other INSERT, DELETE, UPSERT, etc. ops.

This message was sent by Atlassian JIRA

Reply via email to