jiangxt2 opened a new issue, #12736:
URL: https://github.com/apache/gravitino/issues/12736
### Version
main branch
### Describe what's wrong
In the Doris JDBC catalog, `ALTER TABLE ADD INDEX` does not validate the
shape of `TableChange.AddIndex.fieldNames` before generating DDL.
`DorisTableOperations.addIndexDefinition()` reads only `getFieldNames()[0][0]`,
so requests containing multiple fields or a nested field path are silently
reduced to the first top-level field.
This is a correctness issue rather than a normal unsupported-operation
failure: Gravitino can report success even though the index created in Doris
does not match the user's request. The Doris CREATE TABLE path already rejects
multiple secondary-index fields, so CREATE and ALTER currently enforce
inconsistent field-shape contracts.
### Error message and/or stacktrace
No error is reported. For example, this request:
```java
TableChange.addIndex(
Index.IndexType.INVERTED,
"idx_ab",
new String[][] {{"col_a"}, {"col_b"}});
```
is currently converted to SQL equivalent to:
```sql
ALTER TABLE `index_test`
ADD INDEX `idx_ab` (`col_a`) USING INVERTED;
```
The operation succeeds and `SHOW INDEX` reports `idx_ab` only on `col_a`;
`col_b` has been silently discarded. A nested path such as `{{"payload",
"nested"}}` is similarly reduced to `payload`.
### How to reproduce
1. Build Gravitino from the main branch and configure a Doris JDBC catalog.
2. Create a Doris table containing at least two columns, such as `col_a` and
`col_b`.
3. Call `alterTable` with `TableChange.addIndex(Index.IndexType.INVERTED,
"idx_ab", new String[][] {{"col_a"}, {"col_b"}})`.
4. Observe that the operation succeeds instead of rejecting the unsupported
field shape.
5. Load the table metadata or run `SHOW INDEX FROM index_test` in Doris and
observe that `idx_ab` contains only `col_a`.
Expected behavior: the Doris connector should require exactly one non-blank
top-level field for a secondary index and reject multiple fields, nested paths,
or empty field shapes before executing DDL. Valid existing single-field index
operations should remain unchanged.
### Additional context
This issue is not a request to add composite-index support to Doris or to
restrict the common `TableChange.AddIndex` API, because other catalogs may
support multiple fields. The validation should remain Doris-specific and should
be consistent between CREATE TABLE index generation and ALTER TABLE ADD INDEX.
Related work:
- #11590 tracked the broader Doris 3.0.x/4.0.x compatibility upgrade.
- #11731 fixed Doris index syntax and added newer-version compatibility, but
the ALTER path still reads only the first field component.
- #11946 and #12013 added index properties to `TableChange.AddIndex`; they
did not change field cardinality or nested-field semantics.
- #3174 tracks asynchronous schema-change progress and does not cover
request-shape validation.
--
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]
