-
Notifications
You must be signed in to change notification settings - Fork 7
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
fix: compilation #128
fix: compilation #128
Conversation
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## main #128 +/- ##
==========================================
- Coverage 65.58% 65.43% -0.16%
==========================================
Files 25 25
Lines 433 434 +1
Branches 15 15
==========================================
Hits 284 284
- Misses 134 135 +1
Partials 15 15
☔ View full report in Codecov by Sentry. |
private final LockManager lockManager; | ||
|
||
public InMemoryFederatedCacheStore(CriterionConverter<Predicate<Catalog>> converter, LockManager lockManager) { | ||
this.converter = converter; | ||
public InMemoryFederatedCacheStore(LockManager lockManager) { |
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.
Having the converter "configurable" through constructor injection is valuable here, because it's very likely that in the future, we'll need an "actual" predicate converter. Even if currently, we only use the alwaysTrue
one.
For context: here the in-mem implementation is not just used for testing, but very likely will be used in production deployments as well, because the cache store is ephemeral in nature. At least a PG (or even Cosmos) one was not done in the past for that exact reason.
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.
I guess the change will happen in the store itself, I mean, it's part of the in-memory implementation behavior, I don't see any value in having it injectable (with all the implementations using the same instance), in the connector stores this converter is instantiated by the stores internally.
What this PR changes/adds
Fix compilation that was broken because of upstream changes
Why it does that
Briefly state why the change was necessary.
Further notes
List other areas of code that have changed but are not necessarily linked to the main feature. This could be method signature changes, package declarations, bugs that were encountered and were fixed inline, etc.
Linked Issue(s)
Closes # <-- insert Issue number if one exists