zhang-arvin commented on issue #13535: URL: https://github.com/apache/gravitino/issues/13535#issuecomment-5865410120
@MyqueWooMiddo — I'd like to take this one (@zhang-arvin). The trace points at the webserver dispatcher (`OperationDispatcher.operateOnEntity`, line 211): for `metalake.paimon.<db>.<table>` the entity lookup does not resolve against the Paimon catalog that owns the table, so Gravitino concludes the object "doesn't exist in Gravitino" and drops the metadata — with `metadata.iceberg.storage=rest-catalog` the catalog registration goes through the auxiliary Iceberg REST catalog path, which is the trigger here. Plan: 1. Reproduce locally: one metalake with a Paimon (JDBC) catalog plus the AUX IRC catalog, Flink 1.18/1.20 connector, then read/write a table that exists in the Paimon catalog. 2. Trace how the dispatcher maps a fully-qualified identifier to a catalog (which catalog wins when two catalogs are present, and what happens when the resolved catalog is not the entity's owner), and make the resolution respect the owning catalog instead of falling through to the REST-catalog provider. 3. Add a unit test for "same table reachable through a Paimon catalog and an Iceberg REST catalog in one metalake" asserting no spurious "entity doesn't exist" path. I'll open a PR once I have the fix and a test. Please assign this to me if convenient. -- 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]
