feat: add column slice stitching - #8660
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
✅ Gate recommendation: approve.
The revision closes the schema-metadata loss path across V2.0–V2.3 and restores stable row-ID loading for readers that add _rowid after opening. The encoded stitching path now preserves the relevant schema and row-identity contracts.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
| data_file, | ||
| )) | ||
| } | ||
| lance_file::concat::FileConcatResult::Unsupported(_) => { |
There was a problem hiding this comment.
I do not think we should do a full blob rewrite during column-slice concatenation. In this mode, workers should write each managed blob payload once into its final sidecar form—packed or dedicated depending on the blob size—and concatenation should stitch only the descriptors and references.
As written, every Lance-managed blob is read back and written again during concatenation. This adds a full extra I/O pass and loses much of the benefit of distributed slice writing. The initial layout does not need to remain optimal forever; a later compaction can re-evaluate and rewrite the blob layout if necessary.
What do you think about making independently referenceable packed and dedicated objects part of the ColumnSlice contract so concatenation never needs to touch the payload bytes?
There was a problem hiding this comment.
Yes, I'm planning to impelment blob reuse index. After that, we could avoid rewriting blobs everytime.
jackye1995
left a comment
There was a problem hiding this comment.
approving pending further optimization
## Problem Callers need to encode independent row ranges once and assemble them in caller-supplied order without decoding and re-encoding. Lance should provide encoded-part validation and final ordinary data-file construction while leaving part storage and orchestration to the caller. ## Behavior DataFileTarget is a runtime-only value for one live assembly operation. It creates the same canonical random file name used by ordinary Lance writes without creating, reserving, or registering an object. Lance does not serialize or restore this value and does not define coordinator restart or cross-process recovery semantics. Each DataFilePart is a runtime view of an ordinary, complete Lance file. Callers choose part paths and order, retain the live target for the operation, and own part storage, cleanup, and commit fencing. Blob v2 writers receive disjoint ID leases and write managed payloads directly beneath the sidecar directory selected by the final target. BlobTargetId only rejects mixing parts assigned to different final targets within one assembly operation. It is not a dataset, base, or object-store identity. The caller must use the same dataset and resolved base for every part write and final assembly. ## Format and ownership No new Lance file, manifest, transaction, target, or part format is introduced. The completed output is an ordinary DataFile committed through the existing transaction path; readers cannot distinguish it from a normally written file. The implementation uses the current file format and existing encoded page-relocation machinery. Callers own target lifetime, part storage, dataset/base association, cleanup, and commit fencing. Lance owns target name generation, part encoding and intrinsic validation, runtime target-identity checks, and final data-file construction. Follow-up to #8660 and Discussion #8615.
This implements the Rust storage-layer artifact stitching proposed in Discussion #8615. Long-running fragment-local rewrites can stage immutable physical row slices and publish only after exact, gap-free coverage has been validated against the fragment snapshot.
Compatible current-version files are concatenated by relocating encoded pages and regenerating metadata and the footer, while unsupported layouts use the existing ordered decode/re-encode fallback. Binary-copy compaction now delegates encoded-file compatibility and footer handling to the same primitive without adopting the column-slice lifecycle.
The public surface in this PR is intentionally Rust-only. Python and Java bindings are deferred until the contract has settled.