Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Support setting key field in MapBuilder #7101
Support setting key field in MapBuilder #7101
Changes from 1 commit
904a95d
53bbbfc
3021550
7cd1529
2e5f1be
ee07f5b
e46da4a
212c7fa
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 this return Err instead? Given it's user input
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.
Updated.
I'm thinking now this check might be unnecessary because
finish
asserts here that there are no null-keys anyway.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.
Yeah, I've removed checking for nullability of the key field. I didn't love that
MapBuilder::with_keys_field
returns aResult
whileMapBuilder::with_values_field
orGenericListBuilder::with_field
do not. We still ensure that we protect against nulls with the existing assertion infinish
.Happy to go back to returning
Result
. Not feeling strongly about this.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 think we still need this check; the check in
finish()
only checks for null values, but the datatype of the key field itself should always be non-nullable. An array could have no null values but still a datatype with nullable = true I believe.I can see how it's awkward for
with_keys_field
to be the only one returningResult
, but it makes sense to me since it has a pre-condition to guard against, and we should take advantage of Rust's type system where possible instead of documenting panics and hoping users read the documentation.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.
Makes sense. Updated
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.
Given a nullable map field is simply out of spec, I personally don't think panicking is wrong and tbh for this sort of invariant it is arguably more correct...
I don't fell strongly but panicking would be more consistent with the rest of the builders
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.
Just for sanity could we get a test that it panics if you try to specify a keys field with the wrong datatype as well