-
Couldn't load subscription status.
- Fork 118
refactor!: rearchitect CommitResult
#1343
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
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1343 +/- ##
==========================================
- Coverage 84.90% 84.87% -0.03%
==========================================
Files 114 114
Lines 28935 28971 +36
Branches 28935 28971 +36
==========================================
+ Hits 24566 24588 +22
- Misses 3200 3213 +13
- Partials 1169 1170 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
98d75fd to
96d8dcc
Compare
96d8dcc to
ee6ff2b
Compare
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.
Approach LGTM
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.
lgtm!
kernel/src/transaction/mod.rs
Outdated
|
|
||
| /// Compute a new snapshot for the table at the commit version. Note this is generally more | ||
| /// efficient than creating a new snapshot from scratch. | ||
| pub fn post_commit_snapshot(&self, engine: &dyn Engine) -> DeltaResult<SnapshotRef> { |
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.
If we know what we just commited, can we construct the snapshot without having to do any work at all?
Not for this PR, but should we have a follow-up?
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.
actually realized this was more complex. removed and tracking in #916
CommitResult, add post-commit-snapshotCommitResult
5794208 to
84e877a
Compare
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.
mostly good, one comment
kernel/src/transaction/mod.rs
Outdated
| self.into_conflicted(commit_version), | ||
| )), | ||
| // TODO: we may want to be more selective about what is retryable | ||
| Err(e) => Ok(CommitResult::RetryableTransaction(self.into_retryable(e))), |
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.
should we not ensure at least that this is an IO error of some sort?
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.
yea i went back-and-forth on this. I expanded the comment and went ahead and made it only do "retryable" on IOError. I think the main item here is to more clearly define what write_json_files can return in error cases. We likely don't want the entirety of Error struct there. opened #1388
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.
lgtm with nits
| )), | ||
| // TODO: we may want to be more or less selective about what is retryable (this is tied | ||
| // to the idea of "what kind of Errors should write_json_file return?") | ||
| Err(e @ Error::IOError(_)) => { |
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.
woah never seen this syntax!
## What changes are proposed in this pull request?
Our current `Transaction::commit(self, engine)` returns a `CommitResult`
but it doesn't retain enough information for a post-commit Snapshot (and
feels a little clunky)
This PR refactors to a new pattern in which `commit` returns a new
`CommitResult` with one of: committed/conflicted/retryable transaction -
each just holds a transaction and a little more metadata instead of the
old Committed/Conflicted pattern.
```rust
// New
pub enum CommitResult {
CommittedTransaction(CommittedTransaction),
ConflictedTransaction(ConflictedTransaction),
RetryableTransaction(RetryableTransaction),
}
// Old
pub enum CommitResult {
Committed {
version: Version,
post_commit_stats: PostCommitStats,
},
Conflict(Transaction, Version),
}
```
This opens the door for a post-commit-snapshot. it requires a bit more
thought/testing but something like:
```rust
pub fn post_commit_snapshot(&self, engine: &dyn Engine) -> DeltaResult<SnapshotRef> {
Snapshot::builder_from(self.transaction.read_snapshot.clone())
.with_log_tail(new_path)
.at_version(self.commit_version)
.build(engine)
}
```
### This PR affects the following public APIs
`CommitResult` API change, new enum + structs for
`CommittedTransaction`, `ConflictedTransaction`, and
`RetryableTransaction`
## How was this change tested?
refactor
What changes are proposed in this pull request?
Our current
Transaction::commit(self, engine)returns aCommitResultbut it doesn't retain enough information for a post-commit Snapshot (and feels a little clunky)This PR refactors to a new pattern in which
commitreturns a newCommitResultwith one of: committed/conflicted/retryable transaction - each just holds a transaction and a little more metadata instead of the old Committed/Conflicted pattern.This opens the door for a post-commit-snapshot. it requires a bit more thought/testing but something like:
This PR affects the following public APIs
CommitResultAPI change, new enum + structs forCommittedTransaction,ConflictedTransaction, andRetryableTransactionHow was this change tested?
refactor