Variant field names not being ordered correctly via UTF-8 byte order
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 68/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- java
- Ambito
- data-engineering
Direzione di ricerca
Inizia con VariantBuilder e Variant.getFieldByKey, quindi riproduci il problema usando un oggetto con un nome di campo del piano supplementare e un numero sufficiente di campi per attivare la ricerca binaria. Verifica che gli ID dei campi seguano l’ordine dei byte UTF-8 e che la ricerca abbia esito positivo per gli oggetti prodotti sia da parquet-java sia da writers conformi alla specifica.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- Java
- Stelle
- 3.1k
- Fork
- 1.6k
- Merge medio
- 6g 16h
- PR unite (30g)
- 36
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/parquet-java
-
Type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
apache/parquet-java#3792 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
apache/parquet-java#3767 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
apache/parquet-java#3695 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
apache/parquet-java#3667 ·
-
Type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
apache/parquet-java#3574 · 1 commento ·
Tutte le issue di apache/parquet-java
Issue simili
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
inu-appcenter/memorIN-backend#288 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
frontend maui-pilot pilot-ask question
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Apertaarea/plugin
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
kestra-io/plugin-kestra#190 ·