feat: add classic and uuid parquet checkpoint path generation #782
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #782 +/- ##
==========================================
- Coverage 84.67% 84.65% -0.02%
==========================================
Files 83 83
Lines 19780 19836 +56
Branches 19780 19836 +56
==========================================
+ Hits 16748 16792 +44
- Misses 2213 2221 +8
- Partials 819 823 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| if !path.is_checkpoint() { | ||
| return Err(Error::internal_error( | ||
| "ParsedLogPath::new_classic_parquet_checkpoint created a non-checkpoint path", | ||
| )); | ||
| } |
There was a problem hiding this comment.
we do this for commits as well, however since the user cannot really do anything about this (we are generating the file name, and deciding what the log folder is), this feels we should catch this at test time. i.e. are we not just validating that the logic we use to generate a path is compatible with how we check if a path is a checkpoint?
In other words, whenever this raises, it points to a bug in our code?
There was a problem hiding this comment.
You're absolutely right—if this check ever fails, it would indicate a bug in our path generation logic rather than something the user can control. Given that this test coverage already exists, we likely don’t need the runtime checks. Do you think there's additional value of keeping the checks? @zachschuermann
There was a problem hiding this comment.
fair - I wonder if we could do better in the future by having the types encode whether or not it is checkpoint etc. (then it wouldn't be a runtime check here - if you have a checkpoint-specific constructor and a checkpoint type then you are guaranteed to get back a checkpoint)
given that this is no different than what we had before (and it's InternalError) how about we take this as a follow up?
@sebastiantia can you make an issue?
I think this is reasonable, I have a few other PRs for checkpoint write support (tracked here #795) that need to merge before I can leverage this code (in #797). But I did plan to merge this as a separate PR for ease of reviews. |
| if !path.is_checkpoint() { | ||
| return Err(Error::internal_error( | ||
| "ParsedLogPath::new_classic_parquet_checkpoint created a non-checkpoint path", | ||
| )); | ||
| } |
There was a problem hiding this comment.
fair - I wonder if we could do better in the future by having the types encode whether or not it is checkpoint etc. (then it wouldn't be a runtime check here - if you have a checkpoint-specific constructor and a checkpoint type then you are guaranteed to get back a checkpoint)
given that this is no different than what we had before (and it's InternalError) how about we take this as a follow up?
@sebastiantia can you make an issue?
…io#782) <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://github.com/delta-incubator/delta-kernel-rs/blob/main/CONTRIBUTING.md 2. Run `cargo t --all-features --all-targets` to get started testing, and run `cargo fmt`. 3. Ensure you have added or run the appropriate tests for your PR. 4. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP] Your PR title ...'. 5. Be sure to keep the PR description updated to reflect all changes. --> <!-- PR title formatting: This project uses conventional commits: https://www.conventionalcommits.org/ Each PR corresponds to a commit on the `main` branch, with the title of the PR (typically) being used for the commit message on main. In order to ensure proper formatting in the CHANGELOG please ensure your PR title adheres to the conventional commit specification. Examples: - new feature PR: "feat: new API for snapshot.update()" - bugfix PR: "fix: correctly apply DV in read-table example" --> ## What changes are proposed in this pull request? <!-- Please clarify what changes you are proposing and why the changes are needed. The purpose of this section is to outline the changes, why they are needed, and how this PR fixes the issue. If the reason for the change is already explained clearly in an issue, then it does not need to be restated here. 1. If you propose a new API or feature, clarify the use case for a new API or feature. 2. If you fix a bug, you can clarify why it is a bug. --> This PR introduces the helper methods: - `new_uuid_parquet_checkpoint` which creates a new `ParsedCheckpointPath<Url>` for a uuid-named parquet checkpoint file at the specified version. The UUID-naming scheme looks like: `n.checkpoint.u.parquet`, where u is a UUID and n is the snapshot version that this checkpoint represents. - `new_classic_parquet_checkpoint` which creates a new `ParsedCheckpointPath<Url>` for a classic-named parquet checkpoint file at the specified version. The classic-naming scheme looks like: `n.checkpoint.parquet`, where n is the snapshot version that this checkpoint represents. - **Updates the `uuid` dependency to always include `v4` and `fast-rng` features:** - This ensures that `uuid::new_v4()` is always available. - The `fast-rng` feature improves performance when generating UUIDs. For more information on the two checkpoint naming-schemes: https://github.com/delta-io/delta/blob/master/PROTOCOL.md#uuid-named-checkpoint https://github.com/delta-io/delta/blob/master/PROTOCOL.md#classic-checkpoint This PR is part of the on-going effort to implement single-file checkpoint write support. For reference, [[link to write API proposal]](delta-io#779) <!-- Uncomment this section if there are any changes affecting public APIs: ### This PR affects the following public APIs If there are breaking changes, please ensure the `breaking-changes` label gets added by CI, and describe why the changes are needed. Note that _new_ public APIs are not considered breaking. --> ## How was this change tested? <!-- Please make sure to add test cases that check the changes thoroughly including negative and positive cases if possible. If it was tested in a way different from regular unit tests, please clarify how you tested, ideally via a reproducible test documented in the PR description. --> - `test_new_uuid_parquet_checkpoint` - verifies UUID-named Parquet checkpoint creation with proper attributes. - `test_new_classic_parquet_checkpoint` - verifies classic-named Parquet checkpoint creation with proper attributes.
What changes are proposed in this pull request?
This PR introduces the helper methods:
new_uuid_parquet_checkpointwhich creates a newParsedCheckpointPath<Url>for a uuid-named parquet checkpoint file at the specified version. The UUID-naming scheme looks like:n.checkpoint.u.parquet, where u is a UUID and n is the snapshot version that this checkpoint represents.new_classic_parquet_checkpointwhich creates a newParsedCheckpointPath<Url>for a classic-named parquet checkpoint file at the specified version. The classic-naming scheme looks like:n.checkpoint.parquet, where n is the snapshot version that this checkpoint represents.uuiddependency to always includev4andfast-rngfeatures:uuid::new_v4()is always available.fast-rngfeature improves performance when generating UUIDs.For more information on the two checkpoint naming-schemes:
https://github.com/delta-io/delta/blob/master/PROTOCOL.md#uuid-named-checkpoint
https://github.com/delta-io/delta/blob/master/PROTOCOL.md#classic-checkpoint
This PR is part of the on-going effort to implement single-file checkpoint write support. For reference, [link to write API proposal]
How was this change tested?
test_new_uuid_parquet_checkpoint- verifies UUID-named Parquet checkpoint creation with proper attributes.test_new_classic_parquet_checkpoint- verifies classic-named Parquet checkpoint creation with proper attributes.