jiangxt2 opened a new issue, #12916:
URL: https://github.com/apache/gravitino/issues/12916
### Version
main branch
### Describe what's wrong
When the Doris catalog loads a table containing a native NGram BloomFilter
index, Doris reports `Index_type=NGRAM_BF`, but Gravitino maps the metadata to
an unrelated existing index type. An ordinary index name falls through the
generic unknown-index fallback and is exposed as `IndexType.INVERTED`, while an
index named `PRIMARY` is intercepted by the legacy name mapping and is exposed
as `IndexType.PRIMARY_KEY`. Neither result represents the native index, and the
`gram_size` and `bf_size` properties are not represented.
Expected behavior: until Gravitino has an accepted NGRAM_BF representation
and property contract, loading the table should fail with a clear
unsupported-operation error that identifies the index name and native type.
Actual behavior: the table load succeeds and returns a fabricated INVERTED
index with an empty property map for an ordinary index name, or a fabricated
PRIMARY_KEY index when the native index is named `PRIMARY`.
### Error message and/or stacktrace
No exception is raised. The incorrect metadata is observable as:
```text
Doris SHOW INDEX: Index_type=NGRAM_BF
Gravitino Table.index() with an ordinary index name: type=INVERTED,
properties={}
Gravitino Table.index() with Key_name=PRIMARY: type=PRIMARY_KEY,
properties={}
```
### How to reproduce
1. Build Gravitino from the main branch and configure a JDBC Doris catalog
against Doris 3.0.6.2 or 4.0.6.
2. Create a Doris table with a string column.
3. Create a native NGRAM_BF index:
```sql
CREATE INDEX `idx_ngram_bf` ON `table_name` (`text_column`) USING NGRAM_BF
PROPERTIES("gram_size"="3", "bf_size"="256");
SHOW INDEX FROM `table_name`;
```
4. Load the table through the Gravitino Doris catalog and inspect
`Table.index()`.
### Additional context
Doris 3.0.6.2 and 4.0.6 both expose NGRAM_BF as a distinct native index
type. The Doris read path also has legacy handling for `Key_name=PRIMARY`, so
exact NGRAM_BF detection must take precedence even when a native NGRAM_BF index
is named `PRIMARY`.
This issue is limited to preventing semantic misclassification. It does not
add a public index enum, CREATE TABLE or ALTER support for NGRAM_BF, or
`gram_size` and `bf_size` property round-trip support. Existing known mappings
and the generic fallback for unrelated unknown index types should remain
unchanged.
--
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]
