FANNG1 commented on issue #14200:
URL: https://github.com/apache/gravitino/issues/14200#issuecomment-6380367798
Thanks for the detailed write-up and analysis.
**On ask 1 — yes, the resolution should stay connector-side.**
`QueryTable` is a data-plane operation, and the Gravitino lance-rest-server
is deliberately a metadata and authorization service. Implementing
`/v1/table/{id}/query` there would mean routing scan and search execution
through the metadata server, which is a poor fit for Gravitino: it loses the
distributed execution Spark already gives you, and it turns the namespace
server into a data path bottleneck. The current boundary — Gravitino vends
metadata and storage options via `describeTable`, and the connector executes
against the dataset directly — is the one we want to keep, and it is the same
boundary that made #13065 a connector-side fix.
So please file the issues/PRs in the lance-spark community:
- FTS: the dispatch gap you identified, where `supportsQueryTable` keys off
a client-side method override rather than actual server capability, so
`impl=rest` never falls back to the existing local per-fragment FTS path.
- `HYBRID_SEARCH`: the missing local execution path (both side queries
hardcoded to `queryTable`).
Feel free to link them here and we will keep an eye on them.
**On ask 2 — agreed, and tracked in #14204.**
Returning the container's default 404 HTML page for spec routes we
intentionally do not implement is a real bug on our side. The spec already
prescribes the behavior: error code `0` (Unsupported) is a common error for
every operation, and REST implementations must map it to HTTP `406 Not
Acceptable` with an `ErrorResponse` body. `LanceExceptionMapper` already
produces exactly that for `UnsupportedOperationException`; the problem is that
unmatched routes never reach it.
Once fixed, the lance clients will classify the failure properly — the Rust
REST client treats the body's `code` as the sole source of truth, so `code: 0`
surfaces as `NamespaceError::Unsupported` instead of today's `Internal` /
"Failed to parse error response". That should also give the connector a clean
signal to branch on for the local fallback.
--
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]
