collado-mike commented on code in PR #2508:
URL: https://github.com/apache/polaris/pull/2508#discussion_r2407861176
##########
polaris-core/src/main/java/org/apache/polaris/core/persistence/PolarisMetaStoreManager.java:
##########
@@ -416,6 +419,38 @@ ResolvedEntityResult loadResolvedEntityByName(
@Nonnull PolarisEntityType entityType,
@Nonnull String entityName);
+ /**
+ * Load a batch of resolved entities given their {@link
EntityNameLookupRecord}. Will return an
+ * empty list if the input list is empty. Order in that returned list is the
same as the input
+ * list. Some elements might be NULL if the entity has been dropped.
+ *
+ * @param callCtx call context
+ * @param entityLookupRecords the list of entity lookup records to load
+ * @return a non-null list of entities corresponding to the lookup keys.
Some elements might be
+ * NULL if the entity has been dropped.
+ */
+ @Nonnull
+ ResolvedEntitiesResult loadResolvedEntities(
Review Comment:
TBH, I can't think of a use case where we would mix `EntityType`s in a
single call. The two immediate use cases I have in mind are
1. Batch loading the principal roles during the authentication step
2. Support for loading TableMetadata from persistence rather than from cloud
storage (this is in concert with https://github.com/apache/polaris/pull/2735
and other future PRs).
In both cases, only a single EntityType is loaded. I used the
`EntityNameLookupRecord` type largely because it is the return type for the
`listEntities` API, but I wanted to avoid fetching all entities in full in the
case that many/most entities are already in cache. Personally, I don't like the
pattern of using parallel list parameters for an API, so I would oppose the
`List<EntityId>, List<EntityType>` option. I am ok with a new `EntityIdAndType`
argument, but I'd also be ok with just supporting the one API that takes in the
`EntityType` and `List<EntityId>` arguments and getting rid of the other option
until a need arises.
--
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]
