You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Wes McKinney (JIRA)" <ji...@apache.org> on 2019/07/29 14:43:00 UTC
[jira] [Resolved] (ARROW-6042) [C++] Implement alternative
DictionaryBuilder that always yields int32 indices
[ https://issues.apache.org/jira/browse/ARROW-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wes McKinney resolved ARROW-6042.
---------------------------------
Resolution: Fixed
Issue resolved by pull request 4956
[https://github.com/apache/arrow/pull/4956]
> [C++] Implement alternative DictionaryBuilder that always yields int32 indices
> ------------------------------------------------------------------------------
>
> Key: ARROW-6042
> URL: https://issues.apache.org/jira/browse/ARROW-6042
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Wes McKinney
> Assignee: Wes McKinney
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> One problem with the current {{DictionaryBuilder<T>}} in some applications is that, if it is used to produce a series of arrays to form a ChunkedArray, it may yield constituent chunks having different index widths. For example:
> {code}
> chunk 0: int8 indices
> chunk 1: int16 indices
> chunk 2: int16 indices
> chunk 3: int32 indices
> chunk 4: int32 indices
> chunk 5: int32 indices
> chunk 6: int32 indices
> {code}
> Obviously this is problematic for these applications. I'm running into this issue in the context of ARROW-3772 where we are looking to decode Parquet data directly to {{DictionaryArray}} without stepping through an intermediate dense decoded stage.
> I'm not sure what to call the class, whether {{DictionaryInt32Builder}} or something similar, but this would be the same API more or less as {{DictionaryBuilder}} but instead use {{Int32Builder}} for the indices rather than {{AdaptiveIntBuilder}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)