[
https://issues.apache.org/jira/browse/PARQUET-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166275#comment-17166275
]
Gabor Szadovszky commented on PARQUET-1684:
-------------------------------------------
Let's move this discussion to this jira.
{quote}[~doss...@gmail.com]: Can it be considered for 1.11.1? I see a release
candidate is out.
{quote}
Strictly speaking this is not a regression in 1.11.0 so not required for
1.11.1. I am not an expert of protobuf (neither in parquet-protobuf) so let me
ask the following questions:
* Do we have a workaround for this issue?
* What do we think about the potential regressions this change may cause?
(1.11.1 shall be 100% compatible with 1.11.0 and should not contain any
regressions that breaks the usage of 1.11.0.)
> [parquet-protobuf] default protobuf field values are stored as nulls
> --------------------------------------------------------------------
>
> Key: PARQUET-1684
> URL: https://issues.apache.org/jira/browse/PARQUET-1684
> Project: Parquet
> Issue Type: Bug
> Components: parquet-mr
> Affects Versions: 1.10.0, 1.11.0
> Reporter: George Haddad
> Assignee: Priyank Bagrecha
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
>
> When the source is a protobuf3 message, and the target file is Parquet, all
> the default values are stored in the output parquet as `{{null`}} instead of
> the actual type's default value.
> For example, if the field is of type `int32`, `double` or `enum` and it
> hasn't been set, the parquet value is `{{null`}} instead of `0`. When the
> field's type is a `string` that hasn't been set, the parquet value is
> {{`null`}} instead of an empty string.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
