-
Notifications
You must be signed in to change notification settings - Fork 332
Extract ResolverFactory from PolarisEntityManager #2148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
dimas-b
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR LGTM as a general refactoring to isolate resolver lifecycle concerns into a dedicated factory.
8a61fb9 to
f4ce8f7
Compare
`PolarisEntityManager.prepareResolver` was the only place that used the `EntityCache`. By introducing an application-scoped `ResolverFactory` the creation of an `EntityCache` is decided only once in `QuarkusProducers`, which will become the only place where `MetaStoreManagerFactory.getOrCreateEntityCache` gets called. Note that the little left-over functionality of `PolarisEntityManager` can be split out to more dedicated interfaces in a follow-up most likely.
f4ce8f7 to
e7ff61e
Compare
snazy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Minor comments
polaris-core/src/main/java/org/apache/polaris/core/persistence/PolarisEntityManager.java
Outdated
Show resolved
Hide resolved
| */ | ||
| public PolarisEntityManager( | ||
| @Nonnull PolarisMetaStoreManager metaStoreManager, @Nullable EntityCache entityCache) { | ||
| @Nonnull PolarisMetaStoreManager metaStoreManager, @Nonnull ResolverFactory resolverFactory) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit:
| @Nonnull PolarisMetaStoreManager metaStoreManager, @Nonnull ResolverFactory resolverFactory) { | |
| @Nonnull PolarisMetaStoreManager metaStoreManager, ResolverFactory resolverFactory) { |
We kind-of agreed that parameters a not-null by default. But I don't mind having it explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while i agree that assuming non-null would be the best default it would seem weird to have only 1 of the parameters annotated like that.
also it would be unjustified to remove the annotation from the 1st parameter as part of this PR, so i add it to the 2nd parameter for consistency.
long term we should starting using https://jspecify.dev/docs/applying/#2-add-nullmarked
* Extract ResolverFactory from PolarisEntityManager (apache#2148) `PolarisEntityManager.prepareResolver` was the only place that used the `EntityCache`. By introducing an application-scoped `ResolverFactory` the creation of an `EntityCache` is decided only once in `QuarkusProducers`, which will become the only place where `MetaStoreManagerFactory.getOrCreateEntityCache` gets called. Note that the little left-over functionality of `PolarisEntityManager` can be split out to more dedicated interfaces in a follow-up most likely. * Run standard (sharable) REST Catalog integrations tests with MinIO (apache#2158) * Run standard (sharable) REST Catalog integrations tests with MinIO Keep special edge case tests (path style, STS endpoint and client-side FileIO) in `QuarkusRestCatalogMinIoSpecialIT`. * fix(deps): update quarkus platform and group (apache#2166) * fix(deps): update dependency io.smallrye.config:smallrye-config-core to v3.13.4 (apache#2165) * Simplify checkPolarisServiceBootstrappedForRealm (apache#2162) * fix(deps): update dependency boto3 to v1.39.12 (apache#2169) * Improve Realm ID resolution for Quarkus 3.24+ (apache#2163) In Quarkus 3.24, it is now possible to retrieve context locals inside HttpServerMetricsTagsContributor. This greatly simplifies our RealmIdTagContributor implementation. It is also now possible to return null from ValueExpressionResolver. This is not a big deal, but still better than returning "". * chore(deps): update plugin jandex to v2.2.0 (apache#2175) * Add muti-platform Docker images staging in the release guide (apache#2039) * fix(deps): update dependency org.apache.commons:commons-text to v1.14.0 (apache#2178) * Rework getOrCreateSessionSupplier (apache#2161) note how all the caller immediately called `get` on the returned `Supplier`. it seems like the `Supplier` was an leaking implementation detail of the `MetaStoreManagerFactor` implementations. * Respond with 409 in case of concurrent Namespace update failures instead of 500 (apache#1989) * NoSQL adoptions * Last merged commit e9267b6 --------- Co-authored-by: Christopher Lambert <xn137@gmx.de> Co-authored-by: Dmitri Bourlatchkov <dmitri.bourlatchkov@gmail.com> Co-authored-by: Mend Renovate <bot@renovateapp.com> Co-authored-by: Alexandre Dutra <adutra@apache.org> Co-authored-by: JB Onofré <jbonofre@apache.org> Co-authored-by: fabio-rizzo-01 <fabio.rizzocascio@jpmorgan.com>
PolarisEntityManager.prepareResolverwas the only place that used theEntityCache.By introducing an application-scoped
ResolverFactorythe creation ofan
EntityCacheis decided only once inQuarkusProducers, which will becomethe only place where
MetaStoreManagerFactory.getOrCreateEntityCachegets called.Note that the little left-over functionality of
PolarisEntityManagercanbe split out to smaller but more dedicated interfaces in a follow-up most likely.