jiangxt2 opened a new issue, #12740:
URL: https://github.com/apache/gravitino/issues/12740
### Version
main branch
### Describe what's wrong
The JDBC Doris catalog fails to change the type of a column that already has
a default value. `DorisTableOperations.updateColumnTypeFieldDefinition()`
preserves the loaded column comment, nullability, and auto-increment state, but
replaces the loaded default with `DEFAULT_VALUE_NOT_SET`.
Doris treats `MODIFY COLUMN` as a complete column definition and requires
the submitted default to match the existing default. Omitting the existing
default therefore causes an otherwise valid type widening to fail instead of
changing only the requested type.
Expected behavior: `UpdateColumnType` should preserve the existing default
expression and let Doris validate whether the new type and the preserved
default are compatible.
Actual behavior: the generated `MODIFY COLUMN` clause omits the default, and
Doris rejects the operation.
### Error message and/or stacktrace
```text
errCode = 2, detailMessage = Can not change default value
```
### How to reproduce
1. Configure a `jdbc-doris` catalog against Doris.
2. Create a table through Gravitino with a non-nullable `VARCHAR(10)` column
whose default value is `seed`.
3. Call `TableCatalog.alterTable()` with `TableChange.updateColumnType()` to
widen that column to `VARCHAR(20)`.
4. Observe that Doris rejects the generated `MODIFY COLUMN` statement
because the existing default is omitted.
Representative API call:
```java
tableCatalog.alterTable(
tableIdentifier,
TableChange.updateColumnType(
new String[] {"col_data"}, Types.VarCharType.of(20)));
```
Expected result: the column type becomes `VARCHAR(20)` and its default
remains `seed`.
Actual result: the operation fails with `Can not change default value`.
### Additional context
Doris validates a type change against a full replacement column definition.
The connector already loads the existing default before generating the ALTER
statement, so it can preserve that value through the existing Doris
default-value converter without adding a parser or reimplementing Doris
compatibility rules.
Issue #9816 and PR #9821 are related default-value serialization work, but
they do not preserve an existing default during `UpdateColumnType`. Issue #3174
tracks generic asynchronous schema-change status and is outside the scope of
this bug.
For nullable columns, Doris JDBC metadata may not preserve the textual
distinction between an absent default and an explicit `DEFAULT NULL`. This fix
should preserve the semantic default representation loaded by the connector
rather than promise exact reconstruction of the original DDL text.
The fix should remain local to the Doris catalog: preserve the loaded
default while building the replacement `JdbcColumn`, keep
`DEFAULT_VALUE_NOT_SET` behavior for columns that genuinely have no default,
and leave type/default compatibility validation to Doris.
--
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]
