Skip to content

fix: Raincloud oracle gains repeated/list column support#267

Merged
dfa1 merged 1 commit into
mainfrom
fix-261-oracle-list-columns
Jul 11, 2026
Merged

fix: Raincloud oracle gains repeated/list column support#267
dfa1 merged 1 commit into
mainfrom
fix-261-oracle-list-columns

Conversation

@dfa1

@dfa1 dfa1 commented Jul 11, 2026

Copy link
Copy Markdown
Owner

Summary

Test plan

  • ./mvnw verify -pl integration -am -Dit.test=RaincloudConformanceIntegrationTest with all 4 slugs hydrated (up to 700MB cap) and flipped to ok locally — 5/5 pass, 0 skipped
  • ./mvnw test (all modules) — green
  • ./mvnw verify -pl integration -am (full IT suite, 304 tests) — green
  • Checkstyle clean

🤖 Generated with Claude Code

RaincloudConformanceIntegrationTest's Parquet oracle previously aborted
on any column with maxRepetitionLevel > 0 (LIST/repeated groups), which
is how Vortex FixedSizeList/List columns round-trip through Parquet —
blocking conformance verification for glove-* and osm-germany-relations.

Rewrite the oracle to iterate top-level schema fields (one CSV cell per
Vortex column, matching CsvExporter's model) instead of leaf columns
(which for a nested field would wrongly emit multiple cells for what
CsvExporter renders as one JSON array/object). Primitive top-level
fields keep the existing physical-type rendering; LIST/STRUCT fields
render via hardwood's row-object API (RowReader.getList/getStruct,
PqList, PqStruct) walked alongside the SchemaNode tree so unsigned
INT32/INT64 detection (#253) still applies at any nesting depth,
mirroring CsvExporter's jsonObject/jsonArray/jsonValue rules exactly.

Verifying against real hydrated data (glove-6b-50d/100d/200d,
osm-germany-relations) surfaced two genuine, separate bugs the
previously-aborting oracle had never let this test path reach:

- CsvExporter.offsetAt only handled I32/I64 list offsets; osm's
  members/tags columns use I16 offsets, throwing VortexException.
  offsets can legally be any integer ptype (the encoder picks the
  narrowest that fits, same as VarBinArray's offsets) (#263).
- ScanIterator.sliceArray had no case for ListArray/FixedSizeListArray,
  so scanning such a column failed whenever its covering flat chunk
  spans several scan windows (misaligned per-column chunk grids) — a
  real reading gap, not only an export-side one (#265).

Both fixed; all 4 slugs now conform end-to-end and flip to `ok` in the
matrix. Full ./mvnw verify (integration + unit, 304 tests) green.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@dfa1 dfa1 merged commit cde6e94 into main Jul 11, 2026
6 checks passed
@dfa1 dfa1 deleted the fix-261-oracle-list-columns branch July 11, 2026 20:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant