[
https://issues.apache.org/jira/browse/SPARK-56637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18084206#comment-18084206
]
Anupam Yadav commented on SPARK-56637:
--------------------------------------
Closing this issue. After deeper review of the Variant spec, the premise here
is incorrect.
The JIRA description conflates the metadata `sorted_strings` flag (bit 4 of the
metadata header, which controls whether dictionary strings are sorted/unique)
with object field ordering. The spec mandates that object field IDs are always
stored in lexicographic order of their corresponding field names — this is not
optional. There is no "sorted" flag in the object value header (bit 5 of
type_info is unused/reserved).
Binary search on resolved field names in `getFieldByKey` is always valid for
spec-compliant variants. The original implementation is correct.
See discussion on PR #55928: https://github.com/apache/spark/pull/55928
> Variant getFieldByKey() on large objects silently fails if variant metadata
> is unsorted
> ---------------------------------------------------------------------------------------
>
> Key: SPARK-56637
> URL: https://issues.apache.org/jira/browse/SPARK-56637
> Project: Spark
> Issue Type: Bug
> Components: Spark Core
> Affects Versions: 4.2.0
> Reporter: Steve Loughran
> Priority: Major
> Labels: pull-request-available
>
> Variant method getFieldByKey(String key) looks up a key by simple walk if key
> count < 32, binary search if above that. But the binary search assumes the
> metadata is sorted. This is optional according to the format spec; there's a
> bit in the variant to indicate whether or not a variant's metadata is unsorted
> Spark Variant class must do a full scan on unsorted variants. (that's
> ignoring the performance penalty of the scans); iceberg has adopted and
> parquet is adopting caching there.
> Parquet has it's own version of this bug,
> https://github.com/apache/parquet-java/issues/3529
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
