[ 
https://issues.apache.org/jira/browse/KUDU-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713156#comment-16713156
 ] 

Adar Dembo commented on KUDU-1563:
----------------------------------

bq. Why would we have the configuration at the session level? Why not put it at 
the operation level? I guess databases do have a session level configuration, 
but it feels odd to me that I am setting at the session level how an {{INSERT 
IGNORE}} should behave. How about we add an argument to the new operation which 
specifies the behavior of that operation?

I agree that operation level is more intuitive and more flexible, though I 
don't really see a use case for that added flexibility. Can you articulate one?

In any case, my concerns are implementation-specific: I am nervous about 
inflating the memory consumption of each operation, and I'm not sure how to 
preserve backwards compatibility in the C++ client's non-PIMPL'ed 
KuduWriteOperation class. If you can address both of these concerns, I'd be 
open to per-operation configuration.


> 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
>            Priority: Major
>              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
(v7.6.3#76005)

Reply via email to