Spec: Avoid struct field conflicts in default values#12841
Conversation
github-actions
Bot
added
the
Specification
rdblue
requested review from
RussellSpitzer,
aokolnychyi,
danielcweeks and
szehon-ho
and removed request for
aokolnychyi
danielcweeks
left a comment
danielcweeks
left a comment
There was a problem hiding this comment.
Agree with clarifying/simplifying the behavior.
wmoustafa
left a comment
wmoustafa
left a comment
There was a problem hiding this comment.
I am fine with the overall direction. However, I think the wording does not address the case when the field within the struct is a struct. Maybe the idea is that the constraint will apply recursively, but either we state that explicitly or simplify the default spec to restrict it to primitive types and maps/arrays.
nastra
left a comment
nastra
left a comment
There was a problem hiding this comment.
LGTM with the suggested wording from @RussellSpitzer
|
|
||
| For example, a struct column `point` with fields `x` (default 0) and `y` (default 0) can be defaulted to `{"x": 0, "y": 0}` or `null`. A non-null default is stored by setting `initial-default` or `write-default` to an empty struct (`{}`) that will use field values set from each field's `initial-default` or `write-default`, respectively. | ||
|
|
||
| | `point` default | `point.x` default | `point.y` default | Data value | Result value | |
There was a problem hiding this comment.
This is really helpful. Thank you for adding it!
RussellSpitzer
left a comment
RussellSpitzer
left a comment
There was a problem hiding this comment.
Looks good to me now, I think it's very clear.
|
Merged! Thank you @rdblue for tightening up the spec here. Long thanks to all the reviewers |
|
Thanks for merging, @RussellSpitzer! And thanks to all the reviewers, too. |
9 participants
This makes a slight change to the spec for v3 default values.
Previously, the spec allowed default values for struct fields in the struct default and in fields. For example, this was valid:
This would result in a different write default depending on whether a field (default to 0) or the struct itself (default fields to -1) was missing. This behavior is difficult to implement correctly and unnecessary. It is also confusing what will happen when attempting to modify the struct's default, which should not change field defaults, and what will be used for a field's initial default.
The proposed change is to always track field defaults in the struct fields. This results in a uniform way to handle a struct: either produce null, or create a non-null default struct from field defaults. Effectively, this means that structs can default to null or non-null (
struct()).Also note that this change does not prevent us from allowing struct-level and field-level defaults in the future. It simply states that for v3, there can be no field defaults from the struct level. We can add them later if there is a use case that requires them.