You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by GitBox <gi...@apache.org> on 2018/07/09 04:40:49 UTC

[GitHub] paul-rogers opened a new pull request #1367: DRILL-6585: PartitionSender clones vectors, but shares field metdata

paul-rogers opened a new pull request #1367: DRILL-6585: PartitionSender clones vectors, but shares field metdata
URL: https://github.com/apache/drill/pull/1367
 
 
   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.
   
   The solution is to add a new method, `TypeHelper.getClonedVector()`, which handles the "new vector from the materialized field of an existing vector" case. Modified the partition sender to use this version.
   
   Moved an existing method to group the "new vector" functions.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services