fix: Handle optional properties in load namespace properties response#3169
fix: Handle optional properties in load namespace properties response#3169geruh wants to merge 1 commit intoapache:mainfrom
Conversation
| properties: Properties = Field(default_factory=dict) | ||
|
|
||
| @field_validator("properties", mode="before") | ||
| @classmethod | ||
| def replace_none_with_dict(cls, v: Any) -> Properties: | ||
| if v is None: | ||
| return {} | ||
| return v |
There was a problem hiding this comment.
| properties: Properties = Field(default_factory=dict) | |
| @field_validator("properties", mode="before") | |
| @classmethod | |
| def replace_none_with_dict(cls, v: Any) -> Properties: | |
| if v is None: | |
| return {} | |
| return v | |
| properties: Properties | None = Field(default_factory=dict) |
how about just
There was a problem hiding this comment.
This would allow none through to the properties field since the default_factory only applies when the field is ommitted from the response. It would be easier to normalize at the deserialization layer to not miss out on the null checks within the code base but we can.
There was a problem hiding this comment.
i think we actually want to pass null through; for this scenario
If the server does not support namespace properties, it should return null for this field.
and make load_namespace_properties return both Properties and None
Nonefor not supportedPropertiesfor none are set
iceberg-python/pyiceberg/catalog/__init__.py
Line 648 in 4071d39
Wdyt?
There was a problem hiding this comment.
From an user perspective, I think it is more convient to always return a dict
Closes #3167
Rationale for this change
The rest spec model
GetNamespaceResponsedefines thepropertiesfield as optional, and nullable. Also, following the description if the rest catalog doesn't support ns properties they should return null.Link: https://github.com/apache/iceberg/blob/0a73da119ff38ee3a98f248b42180caa51001cec/open-api/rest-catalog-open-api.yaml#L4146-L4163
Looks like the pydantic models raise a
ValidationErrorin the optional/null cases as seen in the issue above. So this PR adds a fix to handle these cases.Are these changes tested?
Yes, added tests and tested with s3tables api
Are there any user-facing changes?
Not really