You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Arina Ielchiieva (Jira)" <ji...@apache.org> on 2020/02/25 13:40:00 UTC

[jira] [Commented] (DRILL-6585) PartitionSender clones vectors, but shares field metdata

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

Arina Ielchiieva commented on DRILL-6585:
-----------------------------------------

[~paul-rogers] could you please clarify the status of this Jira?

> PartitionSender clones vectors, but shares field metdata
> --------------------------------------------------------
>
>                 Key: DRILL-6585
>                 URL: https://issues.apache.org/jira/browse/DRILL-6585
>             Project: Apache Drill
>          Issue Type: Bug
>    Affects Versions: 1.13.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>            Priority: Major
>
> See the discussion forĀ [PR #1244 for DRILL-6373|https://github.com/apache/drill/pull/1244].
> The PartitionSender clones vectors. But, it does so by reusing the {{MaterializedField}} from the original vector. Though the original authors of {{MaterializedField}} apparently meant it to be immutable, later changes for maps and unions ended up changing it to add members.
> When cloning a map, we get the original map materialized field, then start doctoring it up as we add the cloned map members. This screws up the original map vector's metadata.
> The solution is to clone an empty version of the materialized field when creating a new vector.
> But, since much code creates vectors by giving a perfectly valid, unique materialized field, we want to add a new method for use by the ill-behaved uses, such as PartitionSender, that ask to create a new vector without cloning the materialized field.



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