feat: allow for concurrent deletes in conflict checker if data_change is false#3982
Conversation
|
ACTION NEEDED delta-rs follows the Conventional Commits specification for release automation. The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification. |
data_change is falsedata_change is false
d97b878 to
02af6b9
Compare
rtyler
left a comment
There was a problem hiding this comment.
This seems reasonable to me, if CI goes green then we're good 👍
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3982 +/- ##
===========================================
+ Coverage 26.24% 74.31% +48.07%
===========================================
Files 124 152 +28
Lines 20157 40385 +20228
Branches 20157 40385 +20228
===========================================
+ Hits 5290 30013 +24723
+ Misses 14506 9024 -5482
- Partials 361 1348 +987 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
28ad3fe to
4e76ac1
Compare
|
My kingdom for a clean CI run |
Head branch was pushed to by a user without write access
lol sorry, needed a cargo fmt. here we go :) |
Signed-off-by: Abhi Agarwal <abhiaagarwal01@gmail.com>
…ta change Signed-off-by: Abhi Agarwal <abhiaagarwal01@gmail.com>
Signed-off-by: Abhi Agarwal <abhiaagarwal01@gmail.com>
fbb716f to
3abb901
Compare
Description
Consider the following case:
This will currently fail, as the state of the write depended on the state of the table at a given time. However, if the contents of the data in that file was only reorganized (ie: with a compact/zorder), then we don't need to consider this a concurrency violation.
Related Issue(s)
An alternative, perhaps more correct protocol-wise approach to #3890
Documentation
Marked as draft as again, I try to stick to the protocol as much as possible and I don't want to create data corruption unintentionally.