-
Notifications
You must be signed in to change notification settings - Fork 84
feat: Update with_commit_info()
API to use create_one()
API
#997
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
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #997 +/- ##
==========================================
- Coverage 84.68% 84.56% -0.12%
==========================================
Files 92 92
Lines 23025 22769 -256
Branches 23025 22769 -256
==========================================
- Hits 19499 19255 -244
+ Misses 2564 2557 -7
+ Partials 962 957 -5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
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.
Awesome start! in an effort to keep changes minimal/targeted, how about we just start with:
- (already implemented)
with_operation(operation: String)
- (new!)
with_engine_commit_info(engine_commit_info: HashMap<String, String>)
and create a separate issue/PR for with_operation_parameters(operation_parameters: HashMap<String, String>
?
I don't think we will want to make kernel version a public/builder-level API and it isn't clear to me that there's utility in the timestamp case either so let's hold off on those.
…ion and engine_commit_info
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.
few comments!
// The engine is required to provide commit info before committing the transaction. If the | ||
// engine would like to omit engine-specific commit info, it can do so by passing pass an | ||
// empty map. |
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.
this shouldn't be true anymore right? can we make the API just consume something like an iterable (string, string) and we just (internally) accumulate in a hashmap?
// The engine is required to provide commit info before committing the transaction. If the | ||
// engine would like to omit engine-specific commit info, it can do so by passing pass an | ||
// empty map. | ||
pub fn with_commit_info(mut self, engine_commit_info: HashMap<String, String>) -> Self { |
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.
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.
I agree, I think with_engine_commit_info
would be a better name too, but then I wasn't sure how to determine whether or not CommitInfo
has been appended to the transaction. Perhaps we could introduce another call called add_commit_info()
that sets a boolean flag?
kernel/src/transaction.rs
Outdated
let hashmap_to_scalar = |hm: Option<&HashMap<String, String>>| -> DeltaResult<Scalar> { | ||
match hm { | ||
Some(map) => { | ||
let pairs = map.iter().map(|(k, v)| (k.clone(), v.clone())); | ||
let map_data = MapData::try_new( | ||
MapType::new(DataType::STRING, DataType::STRING, false), | ||
pairs, | ||
)?; | ||
Ok(Scalar::Map(map_data)) | ||
} | ||
None => { | ||
let map_data = MapData::try_new( | ||
MapType::new(DataType::STRING, DataType::STRING, false), | ||
std::iter::empty::<(String, String)>(), | ||
)?; | ||
Ok(Scalar::Map(map_data)) | ||
} | ||
} | ||
}; |
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.
I wonder if we could/should implement From<HashMap>
or rather something like From<Iterator<(K, V)>>
for Scalar
?
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.
Co-authored-by: Zach Schuermann <[email protected]>
with_commit_info()
API with multiple APIs to provide CommitInfo
data and materialize it during commit()
with_commit_info()
API to use create_one()
API
Fixes #762
What changes are proposed in this pull request?
To append Commit Provenance Information to a transaction, the current implementation provides an API called
with_commit_info()
that takes in the data forengine_commit_info
in the form ofEngineData
. Instead, this PR proposes to change the name intowith_engine_commit_info()
and take in aHashMap<String, String>
as data. This data will be materialized intoEngineData
duringcommit()
using the newcreate_one()
API.Additionally, this PR removes old test cases that validate the schema of engine_commit_info.
This PR affects the following public APIs
renaming
with_commit_info(EngineData)
-->with_engine_commit_info(HashMap<String, String>)
in transactions.rsHow was this change tested?
I ran
cargo nextest run
and passed all tests