[Bug report] Doris JDBC catalog does not honor DeleteIndex ifExists=true for missing indexes
- Dominant language
- Java
- Stars
- 3.2k
- Forks
- 935
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 298
Description
### Version
main branch; Doris 3.0.6.2 and 4.0.6
### Describe what's wrong
The Doris JDBC catalog does not honor the `TableChange.deleteIndex(name, ifExists)` contract when the target index is missing. Calling `TableChange.deleteIndex("missing_index", true)` on an existing table still generates `DROP INDEX` inside the connector's combined `ALTER TABLE` statement, so Doris returns an index-not-found error instead of treating the change as a no-op.
The expected behavior is that `ifExists=true` succeeds without issuing a DROP fragment when the index is absent, while `ifExists=false` continues to fail before DDL execution. Deleting an existing index must continue to work with either flag.
### Error message and/or stacktrace
The generated `ALTER TABLE ... DROP INDEX ...` statement is sent to Doris and returns an index-not-found error for the missing index. The exact raw Doris/JDBC response is not included here.
### How to reproduce
1. Create an existing table in a Doris JDBC catalog without an index named `missing_index`.
2. Call the table catalog with the following change:
```java
tableCatalog.alterTable(
tableIdentifier,
TableChange.deleteIndex("missing_index", true));
```
3. Observe that the operation fails with an index-not-found error.
4. Verify the behavior matrix: missing index with `ifExists=true` currently fails after DDL submission; missing index with `ifExists=false` fails before DDL with the client-side `IllegalArgumentException`; existing index with either flag succeeds.
### Additional context
Doris documents `IF EXISTS` for standalone `DROP INDEX` syntax, while the Gravitino Doris connector batches compatible table changes into one `ALTER TABLE` statement. The fix should preserve that batching model, omit only the missing-index no-op fragment, and avoid swallowing unrelated SQL, authorization, connection, or schema-change failures.
As a batch safety constraint for the same combined ALTER path, duplicate deletes of the same index and same-name AddIndex/DeleteIndex combinations should fail fast in either request order, regardless of the `ifExists` flag. A missing-index no-op may be combined only with unrelated supported changes; unrelated real changes must remain in the generated ALTER statement.
Relevant Doris documentation: https://doris.apache.org/docs/dev/sql-manual/sql-statements/table-and-view/index/DROP-INDEX
Contributor guide
Research direction
Start at the Doris JDBC catalog's tableCatalog.alterTable path and trace handling for TableChange.deleteIndex(name, ifExists), especially the combined ALTER TABLE generation. Use the stated behavior matrix to verify missing and existing indexes with both flag values, plus duplicate and AddIndex/DeleteIndex cases. Done means missing ifExists=true changes omit only the no-op fragment, while real changes remain batched and unrelated failures are preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100