dimakuz opened a new pull request, #1758: URL: https://github.com/apache/iceberg-go/pull/1758
Fixes #1757. `Set` was the only mutator on `RoaringPositionBitmap`, so range-shaped deletes (dead blocks or row groups) cost one call per position and serialized as array or dense bitmap containers. This adds, mirroring Java's `RoaringPositionBitmap`: - **`SetRange(startInclusive, endExclusive uint64)`** — marks `[start, end)` with one roaring `AddRange` per 2^32-position bucket (Java: `setRange`). - **`RunLengthEncode()`** — re-encodes each bucket's containers as runs where smaller (Java: `runLengthEncode`). - **`SerializeDV`** now run-length encodes before emitting bytes, matching `BitmapPositionDeleteIndex.serialize`. For 100,000 contiguous positions the DV envelope drops from 8,235 to 49 bytes; output remains spec-valid (run containers are flagged in the portable format's cookie header). Two deliberate deviations from Java, documented in the code: an inverted range is a no-op rather than an exception (no mutator on this type panics or errors, and uint64 already excludes Java's negative-position case), and `RunLengthEncode` returns nothing (roaring's `RunOptimize` doesn't report whether it changed anything). ## Testing - New unit tests: range within/spanning/ending-on bucket boundaries, empty and inverted ranges, `SetRange`≡`Set`-loop equivalence, serialized-size reduction with round-trip membership/cardinality equality. - New cross-client test rebuilds Java's `all-container-types-position-index.bin` fixture (132,561 positions across array/run/dense containers in two buckets) via `SetRange`/`Set` and asserts the Go envelope is byte-identical to Java's 94 bytes — it passes only with serialize-time run encoding, pinning the parity decision. - Existing Java golden fixtures still match byte-for-byte; the comment on `TestCrossClientGoSerializeMatchesJavaSingleArrayContainer` that described the old serialize-time divergence from Java is corrected to match. - `go test ./...`, `gofmt`, `golangci-lint run` all clean locally. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
