Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Support the proposed DictionaryEncoding.custom_metadata (format 1.6) for dictionaries of extension types in IPC

未关闭
  • 哪里不对？
#475 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@CurtHagenlocher 已经在做这个了。

开始于 2026年10月19日。

  • #476 来自 @CurtHagenlocher —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
42/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
csharp
领域
backend, databases

调研方向

Start by reading ArrowStreamWriter.GetFieldMetadataOffset and MessageSerializer.FieldFromFlatbuffer, then inspect the generated FlatBuffers types and the existing IPC tests. Implement the format 1.6 dictionary value metadata handling in the writer and reader, preserving field metadata for the whole dictionary type. Add the .NET archery dictionary_extension integration case and verify the new behavior against the proposed semantics; the issue notes this work depends on the format vote passing.

由索引模型根据 Issue 内容生成。

描述

Describe the enhancement requested

In IPC, a dictionary-encoded field has no separate schema node for its value type, so dictionary<values=extension<X>> and extension<X, storage=dictionary<...>> serialize identically, with ARROW:extension:name in Field.custom_metadata. This is tracked upstream as apache/arrow#49704. A format change proposed in apache/arrow#53994 (format version 1.6) adds an optional DictionaryEncoding.custom_metadata that holds the dictionary value type's metadata. That's the IPC counterpart of ArrowSchema.dictionary->metadata in the C Data Interface. Field.custom_metadata keeps describing the whole dictionary type.

The format change is a draft pending a [VOTE] on dev@. Companion PRs: apache/arrow-go#1381, apache/arrow-rs#11622, apache/arrow-nanoarrow#972. This issue is to implement it in Apache.Arrow once the vote passes.

Current Apache.Arrow behavior

  • Writer: ArrowStreamWriter.GetFieldMetadataOffset puts a dictionary value type's extension keys in Field.custom_metadata, which is the same encoding as an extension over a dictionary.
  • Reader: MessageSerializer.FieldFromFlatbuffer resolves Field.custom_metadata against the value type before wrapping it in a DictionaryType, so it reads field-level keys as describing the values. That's the opposite of Arrow C++ and of the proposed spec. As a result:
    • an extension over a dictionary written by Arrow C++ doesn't resolve;
    • Arrow C++ can't read a dictionary<int32, arrow.uuid> written by Apache.Arrow (Invalid storage type for UuidType: dictionary<...>); it can't read the one it writes itself today either.

Proposed work (after the vote)

  1. Regenerate the flatbuffers code for the new DictionaryEncoding.custom_metadata member.
  2. Writer: put a value extension type's ARROW:extension:* keys in DictionaryEncoding.custom_metadata instead of Field.custom_metadata. An extension over a dictionary keeps its keys on the field.
  3. Reader: apply DictionaryEncoding.custom_metadata to the value type before wrapping it in the dictionary type, then apply Field.custom_metadata to the whole dictionary type.
  4. Add the archery dictionary_extension integration case for .NET.

Decision: field-level keys on a dictionary follow the spec, with no fallback

Field.custom_metadata on a dictionary-encoded field describes only the whole dictionary type, as in Arrow C++ and arrow-go, and the reader won't retry it against the value type. Breaking change: dictionary<extension> files written by earlier Apache.Arrow versions (and by every writer before 1.6) will read as a plain dictionary of the storage type, so this needs a release note. #474 makes the same choice for C Data import.

The C Data side is aligned with these semantics in #474.

Component(s)

C#

主要语言
C#
星标
42
派生
32
平均合并
1 天 3 小时
30 天内合并 PR
25

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/arrow-dotnet 的其他 Issue

查看 apache/arrow-dotnet 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。