[
https://issues.apache.org/jira/browse/KUDU-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868509#comment-15868509
]
Todd Lipcon commented on KUDU-1881:
-----------------------------------
When you say "deserializing a scan token", I'm not sure quite what you mean.
Deserialization doesn't talk to the server, does it? Should the check be when
the scanner is opened? Keep in mind that the schema could change in between
when we call OpenTable and when we call Open on the scanner -- so maybe we're
missing a check in that latter part?
> Deserializing scan token should check nullability of column
> -----------------------------------------------------------
>
> Key: KUDU-1881
> URL: https://issues.apache.org/jira/browse/KUDU-1881
> Project: Kudu
> Issue Type: Bug
> Components: client
> Affects Versions: 1.2.0
> Reporter: Matthew Jacobs
> Assignee: Dan Burkert
> Priority: Critical
> Fix For: 1.3.0
>
>
> When deserializing a scan token, the projection schema must be validated
> against that of the table to ensure projected columns haven't been changed.
> While the data types are validated, the nullability of those columns is not.
> If a column 's' with nullable=false is dropped and then add 's' with
> nullable='true' (or visa-versa), clients will expect tuples to have the wrong
> memory layout. Systems like Impala that memcpy the tuples directly can crash
> as a result.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
