[
https://issues.apache.org/jira/browse/KUDU-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15646042#comment-15646042
]
Matthew Jacobs commented on KUDU-1563:
--------------------------------------
[~brocknoland], how far along are you on this? I've done a lot of thinking and
work in handling errors on the Impala side, and I have some thoughts about this
work.
It seems to me that this work is addressing the following problem: duplicate
key errors are very common and all the overhead of sending error msgs back to
the client is very expensive. It makes sense that we basically want to push
down some error handling. However, as I think about this from a client
perspective, this is only 1 of several errors that I might want to handle this
way, and I'd also want it to apply to other operation types. I'd really want a
way to say "here's an INSERT/UPDATE/DELETE op, and BTW ignore error types X and
Y".
E.g. I'd like to be able to say, do an INSERT and ignore duplicate keys. But
also, do an UPSERT (or INSERT) and ignore cases where the PK is not in a
covered range. Also: do an UPDATE/DELETE and ignore cases where maybe there's
no row found for the PK. It's not that we'd have to handle every case right
now, but I think we'd get a lot of benefit from having an interface where we
can specify error codes to handle for different ops. Does that make sense?
> Add support for INSERT IGNORE
> -----------------------------
>
> 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
(v6.3.4#6332)
