bharos opened a new pull request, #11046:
URL: https://github.com/apache/gravitino/pull/11046
### What changes were proposed in this pull request?
Replace the per-identifier loop dispatch for the \`GROUP\` entity in
\`JDBCBackend.batchGet\` with a true batch SQL SELECT.
- New \`batchSelectGroupMetaByMetalakeIdAndNames\` SQL on
\`GroupMetaBaseSQLProvider\` using MyBatis \`<script><foreach>\` for a portable
IN-clause; honors soft delete and hits the indexed \`(metalake_id,
group_name)\` columns. No DB-specific overrides required.
- Wired through \`GroupMetaMapper\` and \`GroupMetaSQLProviderFactory\`.
- New \`GroupMetaService.batchGetGroupByIdentifier(List<NameIdentifier>)\`:
- Empty/null input -> empty list (no DB call).
- Per-identifier \`AuthorizationUtils.checkGroup\` plus cross-identifier
same-namespace \`Preconditions\` check.
- Single transaction via \`SessionUtils.doWithCommitAndFetchResult\`; role
hydration happens inside the same session (reuses the ThreadLocal
\`SqlSession\`).
- \`@Monitored\` instrumented.
- \`JDBCBackend.batchGet\` \`case GROUP\` now dispatches to the new path.
The \`USER\` case TODO comment is updated to "users, roles, and views" to
reflect remaining work.
### Why are the changes needed?
The previous GROUP path issued one SELECT per identifier (N round trips per
batch). For authorization paths that resolve many groups (e.g. group-inherited
roles), this added significant latency. This change brings GROUP in line with
the batch SQL implementations already used for Metalake, Catalog, Schema,
Table, Topic, Model, Tag, Policy, Job, and JobTemplate.
Related: #3989 (umbrella batch load API for multiple entities). Follow-up to
#10933 (handle missing entities in batch).
### Behavior contract (consistent with sibling batches)
- Missing groups -> silently skipped (no \`NoSuchEntityException\`).
- Duplicate identifiers -> deduped (SQL IN semantics).
- Result order is not preserved.
- All identifiers must share a namespace; mixed-namespace input fails fast
with \`IllegalArgumentException\`.
### Does this PR introduce _any_ user-facing change?
No. Internal storage-layer change; behavior of \`EntityStore.list(...,
GROUP)\` and direct callers of \`JDBCBackend.batchGet\` for GROUP is unchanged
from a contract perspective. Only the number of SQL round-trips is reduced.
### How was this patch tested?
- New unit test \`testBatchGetGroups\` covers happy-path multi-group
retrieval and verifies role attachment (1 group with 2 roles, 2 groups with no
roles).
- Existing \`testBatchGetGroupsPartialResults\` validates that missing
groups are skipped.
- \`./gradlew :core:test --tests
"org.apache.gravitino.storage.relational.TestJDBCBackendBatchGet.testBatchGetGroups"
--tests
"org.apache.gravitino.storage.relational.TestJDBCBackendBatchGet.testBatchGetGroupsPartialResults"
-PskipITs\` -> all pass.
- \`./gradlew :core:spotlessApply\` -> clean.
--
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]
