Stephen0421 opened a new pull request, #10675:
URL: https://github.com/apache/paimon/pull/10675
### Purpose
`SchemaManager.commit_changes` silently ignored
`UpdateColumnDefaultValue`: the
change was accepted but never applied, so a column default could not be
set,
changed or cleared from Python. This PR applies it and validates the value
against the target type before storing it.
- Validation mirrors the Java `DefaultValueUtils` string casts for
booleans,
numbers, dates, times and timestamps. The stored value is still the
original
string; only castability is checked.
- `UpdateColumnDefaultValue.new_default_value` is widened from `str` to
`Optional[str]`, matching the `@Nullable` contract of
`DefaultValueUtils#validateDefaultValue` on the Java side, where `None`
clears the default. `SchemaChange.update_column_default_value` is
widened to
match.
- Nested fields are supported through the existing `_update_nested_column`
path, the same way `UpdateColumnComment` works.
- An invalid value raises before anything is written, so no partial schema
is
committed.
Known gap: Java also accepts `ARRAY`, `MAP` and `ROW` defaults via
`StringToArrayCastRule`, `StringToMapCastRule` and `StringToRowCastRule`.
Python does not parse those forms yet and rejects them with an explicit
message rather than accepting a value it cannot validate.
### Tests
`pypaimon/tests/schema_manager_test.py` adds
`TestUpdateColumnDefaultValue`:
- Set, change and clear a default, including on a nested struct field.
- Reject a value that does not match the column type, and reject a missing
column; assert the schema id does not advance in either case.
- Reject an `ARRAY` default with the explicit unsupported-type message.
- Two parametrized tables of scalar values that Java accepts and rejects.
Every case was checked against a compiled `DefaultValueUtils` before
being
added, covering the boundaries that are easy to get wrong: `INT`
accepting
`".5"` and `"10."`, `DOUBLE` accepting `"0x1.0p0"` and `" 1.5 "` but not
`"1_000"`, negative epochs for `DATE`/`TIME`/`TIMESTAMP`, `TIME` not
bounding its components, the timestamp formatter's SMART resolver
clamping
day-of-month, and `TIMESTAMP` accepting an epoch while `TIMESTAMP_LTZ`
does
not.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
