Variant field names not being ordered correctly via UTF-8 byte order
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 68/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- java
- Área
- data-engineering
Línea de trabajo
Comienza con VariantBuilder y Variant.getFieldByKey; después, reproduce el problema usando un objeto con un nombre de campo del plano suplementario y suficientes campos para activar la búsqueda binaria. Verifica que los identificadores de campo sigan el orden de bytes UTF-8 y que la búsqueda funcione correctamente para objetos producidos tanto por parquet-java como por writers conformes con la especificación.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug, including details regarding any error messages, version, and platform.
The Variant spec requires the field ids in an object's header to be sorted by the
UTF-8 byte order of the field names, so a reader can binary-search them.
VariantBuilder sorted the fields — and Variant.getFieldByKey binary-searched them —
using String.compareTo, which orders by UTF-16 code units, not UTF-8 bytes.
The two orderings are identical for all field names in the Basic Multilingual Plane, but
they diverge for names containing supplementary-plane characters (U+10000 and above):
String.compareTo orders a leading high surrogate (0xD800–0xDBFF) before code points in
U+E000..U+FFFF, whereas UTF-8 byte order (and the spec) orders them after. Consequences:
- An object parquet-java builds with such keys has field ids sorted in an order that
violates the spec. - A spec-compliant reader (e.g. the Apache Arrow C++/Rust/Go Variant readers) binary-searching
that object can fail to find fields. - Conversely, parquet-java's own binary search fails to find a supplementary-plane key in an
object produced by a spec-compliant writer.
The bug only surfaces when an object both contains a supplementary-plane key and is large
enough to take the binary-search path, so it has gone unnoticed.
Component(s)
Core
- Lenguaje dominante
- Java
- Estrellas
- 3.1k
- Forks
- 1.6k
- Merge medio
- 6 d 16 h
- PR fusionados (30 d)
- 36
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/parquet-java
-
Type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
apache/parquet-java#3792 ·
-
Make PageReader AutoCloseable Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/parquet-java#3767 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
apache/parquet-java#3695 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
apache/parquet-java#3667 ·
-
Type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
apache/parquet-java#3574 · 1 comentario ·
Todos los issues de apache/parquet-java
Issues similares
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
inu-appcenter/memorIN-backend#288 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
frontend maui-pilot pilot-ask question
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Abiertoarea/plugin
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
kestra-io/plugin-kestra#190 ·