Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#475 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@CurtHagenlocher ya está trabajando en esto.

Desde el 19/10/2026.

  • #476 de @CurtHagenlocher — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp
Área
backend, databases

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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#

Lenguaje dominante
C#
Estrellas
42
Forks
31
Merge medio
1 d 1 h
PR fusionados (30 d)
24

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/arrow-dotnet

Todos los issues de apache/arrow-dotnet

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.