Repository navigation
chore(deps): arrow 55 -> 59, hotdata 0.16.0 - #286
Conversation
Results are fetched as Arrow and rendered here with arrow-json, the same encoder the service uses. Until now the two ran different arrow majors, so they agreed because they were observed to and not because anything pinned them — and a drift in how a nested value is written would have surfaced as wrong output rather than a build failure. This puts both on the same major. Both moves are required together: arrow types cross the SDK's public API, so its arrow major is effectively ours. Bumping one alone builds two arrow trees and fails to compile, since types from two majors are distinct even where they look identical. No source changes. Only the two dependency lines move.
There was a problem hiding this comment.
Dependency bump only. Both lines have to move together, and the diff moves both. Cargo.lock resolves hotdata 0.16.0 and the full arrow 59.3.0 tree consistently, with no second arrow major left in the graph.
The ipc, chrono-tz and json features still exist on arrow 59, and the arrow-json items this crate imports (EncoderOptions, NullableEncoder, make_encoder in src/commands/query.rs:5) are still public there.
Note on CI: only CI / changelog reported success at review time. CI / fmt and CI / test were still pending, so this approval does not confirm the suite passed.
nit: stale comment in src/commands/query.rs:126-129 (not blocking).
Inline comments cannot anchor there, because the file is outside the diff. The ENCODER_OPTIONS doc comment says the service runs a later arrow than the SDK, and that aligning the two needs an SDK release first. This PR is that release. A reader hitting those lines after merge will look for a version gap that no longer exists. Rewrite the caveat to state that the CLI and the SDK now share arrow 59, and keep the one real asymmetry (this path builds a Value, the service writes bytes straight to the response), which encode_cell already documents.
super nit: the arrow 55 vs 59 rendering table in the description is the strongest evidence in this PR, and nothing in the repo records it (not blocking). A CHANGELOG entry, or a comment above the arrow dependency in Cargo.toml:43, would keep that result findable after the PR scrolls out of view.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Summary
Two dependency lines. No source changes.
Results are fetched as Arrow IPC and rendered here with arrow-json, the same encoder the service uses for its inline JSON. Until now the two ran different arrow majors, so they agreed because they were observed to and not because anything pinned them together. A change in how a nested value is written across an arrow major would have shown up as wrong output rather than a build failure. This puts both on the same major.
Why both lines have to move together
Arrow types cross the SDK's public API —
ArrowResulthands backRecordBatchandSchemaRef— so the SDK's arrow major is effectively this crate's. Bumping either alone builds two arrow trees and fails:hotdata0.16.0 is the SDK release that moved to arrow 59.Verification
cargo build— clean against the published crate;Cargo.lockresolveshotdata0.16.0 from crates.io andarrow-array59.3.0cargo fmt --check,cargo clippy --all-targets -- -D warnings— cleanRendering was also checked against a live service, comparing the inline answer to the same result fetched from storage, on both arrow majors:
So arrow 55 and 59 render identically today — nothing was broken by the gap. The value here is that the two are now pinned to the same major rather than agreeing by coincidence, since nothing in CI compares client rendering against the service.
Note
No behaviour change is expected, so there is no CHANGELOG entry beyond what the dependency bump implies. Happy to add one if you would rather it be visible in the release notes.