-
Notifications
You must be signed in to change notification settings - Fork 86
feat: add SnapshotManager #542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The test cases are derived from Java's TestSnapshotManager.java. Since MergeAppend is not supported yet, some tests are omitted for now and can be added later.
evindj
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM only question that I have is why is UpdateSnapshotReference and SnapShotManager both exposed. Also, is there a way we can integration test this change?
| protected: | ||
| // These snapshot IDs correspond to the snapshots in the TableMetadataV2Valid.json | ||
| static constexpr int64_t kOldestSnapshotId = 3051729675574597004; | ||
| static constexpr int64_t kCurrentSnapshotId = 3055729675574597004; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since the metadata file is read in the base test setup, will it make sense to extract these in variables instead of copy pasta?
| /// and tags) and commit the changes. | ||
| Result<std::shared_ptr<UpdateSnapshotReference>> NewUpdateSnapshotReference(); | ||
|
|
||
| /// \brief Create a new SnapshotManager to manage snapshots. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you be a bit more descriptive here especially how it differs from NewUpdateSnapshotReference() I am a little confuse as to why the transaction would expose both since SnapshotManager seems to be a wrapper on top of UpdateSnapshotReference
| ~SnapshotManager() override; | ||
|
|
||
| // TODO(xxx): is this correct? | ||
| Kind kind() const final { return Kind::kUpdateSnapshotReference; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to https://github.com/apache/iceberg-cpp/blob/main/src/iceberg/update/update_snapshot_reference.h this looks correct. But would still probably want to wait for someone who knows more about this space.
|
|
||
| SnapshotManager& SnapshotManager::Cherrypick(int64_t snapshot_id) { | ||
| ICEBERG_BUILDER_RETURN_IF_ERROR(CommitIfRefUpdatesExist()); | ||
| // TODO(anyone): Implement cherrypick operation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an issue for this?
The test cases are derived from Java's TestSnapshotManager.java. Since MergeAppend is not supported yet, some tests are omitted for now and can be added later.