You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Alexey Serbin (Jira)" <ji...@apache.org> on 2019/09/25 01:11:00 UTC

[jira] [Commented] (KUDU-2625) Unexpected behavior of WriteBatch wrt rows violating schema constraints

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

Alexey Serbin commented on KUDU-2625:
-------------------------------------

It seems I'm late with my answer, but I think we can have this fix only starting version 1.11.  I'm not sure whether there is a high demand for this fix in the maintenance branches.

> Unexpected behavior of WriteBatch wrt rows violating schema constraints
> -----------------------------------------------------------------------
>
>                 Key: KUDU-2625
>                 URL: https://issues.apache.org/jira/browse/KUDU-2625
>             Project: Kudu
>          Issue Type: Bug
>          Components: tablet, tserver
>    Affects Versions: 0.5.0, 0.6.0, 0.7.0, 0.7.1, 0.8.0, 0.9.0, 0.9.1, 1.0.0, 1.0.1, 1.1.0, 1.2.0, 1.3.0, 1.3.1, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.7.1
>            Reporter: Alexey Serbin
>            Assignee: Yingchun Lai
>            Priority: Critical
>             Fix For: 1.11.0
>
>         Attachments: example.cc
>
>
> While decoding write operation sent using {{WriteRequestPB}}, tablet servers reject the whole batch if there is a row that violates table schema constraints (e.g., presence of null values for non-nullable columns).  That behavior is different from the case when errors happen at later stages of 'applying' received write operations (e.g., a duplicate key error).  In most cases, the user expects only 'bad' rows to be rejected, but in case of schema violation constraints whole batch of operations received by a tablet server is rejected.  Maybe, that behavior should be configurable, but at least there should be an option to reject only the 'bad' rows and most likely that should be the default.  Current behavior violates the [POLA principle|https://en.wikipedia.org/wiki/Principle_of_least_astonishment] and should be fixed.
>  
> A reproduction scenario in Groovy for the described behavior using Java Kudu client is at https://gist.github.com/boristyukin/8703d2c6ec55d6787843aa133920bf01
> Another reproduction scenario uses C++ client: see the attached {{example.cc}} file.  The example can be compiled as an example C++ Kudu client application; see instructions at https://github.com/apache/kudu/blob/master/examples/cpp/README.adoc



--
This message was sent by Atlassian Jira
(v8.3.4#803005)