geyanggang commented on PR #13481: URL: https://github.com/apache/gravitino/pull/13481#issuecomment-5865877911
@yuqi1129 Thanks — the authorize-vs-operate mismatch was the right thing to block on. Fixed by making authorization and the operation resolve the physical name through one shared path: Added CapabilityHelpers.resolvePhysicalTableName(normalizedIdent, catalogManager) as the single resolver. MetadataIdConverter.normalizeCaseSensitive now applies it for TABLE scope, so getID authorizes the resolved identifier — the same one the dispatcher operates on. TableNormalizeDispatcher calls the same helper (its private resolver is gone). Dropped the requested-name-first rule and the requestedIdent parameter — the SPI is now resolveTableName(NameIdentifier normalizedIdent). As you said, an unquoted orders already means ORDERS under a folding capability, and quoted input is preserved by normalization; matching the requested name case-sensitively is what made timeline 1 reachable. This closes both timelines: the authorizer and the dispatcher compute the same physical name from the same normalized input, so the check and the action always target the same table. Cost is isolated to opt-in catalogs. The resolver reuses the single doWithCatalog that getCapability already performs; for any catalog that does not implement SupportsTableNameResolution (all of them today) it is an instanceof check that returns the normalized name — no extra doWithCatalog, no source access. Only a catalog that opts in touches its source, and getID is behind the two-tier authorization cache. Added a test (TestMetadataIdConverter.testTableAuthorizationResolvesPhysicalNameSameAsDispatcher) pinning the authorization lookup and the resolution to the same identifier. Verified: core catalog (300), jdbc-common (48), server-common (378) unit suites, plus real-container Postgres/MySQL table-op tests. -- 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]
