-
Notifications
You must be signed in to change notification settings - Fork 201
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
Remove all tightly coupled EntityCache dependencies in the main persistence stack #1055
Remove all tightly coupled EntityCache dependencies in the main persistence stack #1055
Conversation
…stence stack Remove the EntityCacheEntry wrapper since the timestamp fields were never used anyways; instead the underlying Caffeine cache transparently handles access times, and the types of entries we cache are simply the existing ResolvedPolarisEntity. Remove interactions of business logic with explicit "cache entries", instead operating on ResolvedPolarisEntity. Fix the equals()/hashCode() behavior of PolarisEntity to be compatible with PolarisBaseEntity as intended. Improve code comments to explain the (current) relationship between PolarisEntity and PolarisBaseEntity, and clarify the behaviors in Resolver.java. Fully remove the PolarisRemoteCache interface and its methods. Add different methods that aren't cache-specific instead.
…erize ResolverTest
* Currently, code that intends to operate directly on a PolarisBaseEntity may not adhere to | ||
* immutability semantics, and may modify the entity in-place. | ||
* | ||
* <p>TODO: Combine this fully into PolarisBaseEntity, refactor all callsites to use strict |
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.
It sounds reasonnable to me to only have PolarisBaseEntity
. PolarisEntity
is a bit confusing at first glance.
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; I think we can fast follow on the PolarisEntity
Following up on apache#1055, this refactoring does not remove `EntityCache`, but allows it to be `null` in principle, should a particular MetaStoreManagerFactory implementation choose not to use an `EntityCache`. * Remove bean producer for `EntityCache` (beans cannot be `null`). * Harmonize all `PolarisEntityManager` producers (explicit and CDI) to go through `RealmEntityManagerFactory` (tangential to the cache being null, but related).
Following up on #1055, this refactoring does not remove `EntityCache`, but allows it to be `null` in principle, should a particular MetaStoreManagerFactory implementation choose not to use an `EntityCache`. * Remove bean producer for `EntityCache` (beans cannot be `null`). * Harmonize all `PolarisEntityManager` producers (explicit and CDI) to go through `RealmEntityManagerFactory` (tangential to the cache being null, but related).
Remove the EntityCacheEntry wrapper since the timestamp fields were never used anyways; instead the underlying Caffeine cache transparently handles access times, and the types of entries we cache are simply the existing ResolvedPolarisEntity.
Remove interactions of business logic with explicit "cache entries", instead operating on ResolvedPolarisEntity. Fix the equals()/hashCode() behavior of PolarisEntity to be compatible with PolarisBaseEntity as intended.
Improve code comments to explain the (current) relationship between PolarisEntity and PolarisBaseEntity, and clarify the behaviors in Resolver.java.
Fully remove the PolarisRemoteCache interface and its methods. Add different methods that aren't cache-specific instead.
Add support for constructing Resolver with null EntityCache to skip all cache interactions entirely.