FANNG1 commented on PR #10560: URL: https://github.com/apache/gravitino/pull/10560#issuecomment-4139551312
This PR needs a clearer user-facing semantic definition before we look at the implementation details. By introducing an in-memory catalog store alongside the existing Gravitino-backed store, this change is no longer only "allow third-party connectors". It also changes the semantics of catalog lifecycle operations from the user perspective. I think the PR description and docs should first clarify: - What is the exact behavior of CREATE CATALOG? - Which catalog types are persisted in Gravitino, and which ones are stored only in Flink memory? - What are the semantics of GET/USE CATALOG, DROP CATALOG, and SHOW/LIST CATALOGS after this change? - Are third-party catalogs session-scoped or process-scoped? Will they disappear after restarting Flink? - What is the expected behavior if the same catalog name exists in both the in-memory store and Gravitino? - Is there a defined precedence when reading or dropping catalogs across the two stores? Right now, the implementation seems to introduce a mixed two-store model, so users need a precise contract for catalog visibility, persistence, and conflict handling. Without that, it is hard to evaluate whether the current behavior is correct or whether edge cases like duplicate names and shadowing are acceptable. -- 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]
