jiangxt2 opened a new issue, #12764:
URL: https://github.com/apache/gravitino/issues/12764
### Version
main branch
### Describe what's wrong
The JDBC Doris catalog accepts a default value in `TableChange.AddColumn`,
but `DorisTableOperations.addColumnFieldDefinition()` does not include it in
the generated `ALTER TABLE ... ADD COLUMN` statement.
For a non-nullable column, Doris may reject the schema change because the
generated definition has no default. For a nullable column, the operation may
succeed while silently discarding the requested default, so later inserts and
`loadTable()` return behavior differ from the caller's request.
Expected behavior: Doris `ADD COLUMN` should preserve supported literal
defaults and `CURRENT_TIMESTAMP`. At the SQL generation boundary, an explicit
null default should emit `DEFAULT NULL`, while `DEFAULT_VALUE_NOT_SET` should
omit the clause.
Actual behavior: the generated ADD COLUMN definition contains the type,
nullability, comment, and position, but omits the requested default.
### Error message and/or stacktrace
Nullable columns may not produce an error and instead lose the requested
default silently. As a separate impact, Doris can reject a non-nullable ADD
COLUMN because the generated definition has no default.
Representative generated SQL:
```sql
ALTER TABLE `test_table`
ADD COLUMN `new_col` varchar(255);
```
The expected definition includes a `DEFAULT` clause before `COMMENT` and
`FIRST`/`AFTER`.
### How to reproduce
1. Configure a `jdbc-doris` catalog against Doris.
2. Create a table through Gravitino.
3. Add a nullable column with a non-null default through
`TableChange.addColumn()`.
4. Load the table or insert a row without specifying the new column and
observe that the requested default was not preserved.
5. Separately, add a non-nullable column with a default and observe that
Doris may reject the ADD COLUMN because the generated definition omits the
default.
Representative API call:
```java
tableCatalog.alterTable(
tableIdentifier,
TableChange.addColumn(
new String[] {"new_col"},
Types.VarCharType.of(255),
null,
TableChange.ColumnPosition.defaultPos(),
true,
false,
Literals.of("default value", Types.VarCharType.of(255))));
```
### Additional context
`TableChange.AddColumn` already exposes `getDefaultValue()`, and other JDBC
catalog implementations consume it when building ADD COLUMN SQL. The fix should
remain local to the Doris catalog and leave type/default validation to Doris.
Doris default-literal parsing differs across supported versions, especially
for backslashes in `ALTER TABLE ... ADD COLUMN`. The implementation should
verify metadata round-trip and omitted-column INSERT semantics on the
repository's Doris 1.2.x, 3.0.6.2, and 4.x baselines without changing CREATE
TABLE or unrelated MODIFY COLUMN serialization.
Issue #839 and PR #2558 introduced AddColumn default support in the public
API. Issue #9816 and PR #9821 addressed shared default serialization, but they
do not make the Doris ADD COLUMN path consume `AddColumn.getDefaultValue()`.
For nullable columns, Doris/JDBC metadata may normalize both an absent
default and an explicit `DEFAULT NULL` to `null`. The required distinction is
therefore at SQL generation time; the issue does not require reconstructing
their original textual difference from metadata.
--
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]
