-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Support index-level request caching #931
Conversation
Cache underlying index requests if they are executed on released content.
...so they can be cached properly
...filter with single valued arrays
* @return whether the search should cache the resulting hits in the underlying index system or not | ||
*/ | ||
protected boolean cacheHits(C context) { | ||
return Revision.class.isAssignableFrom(getFrom()) && context.optionalService(PathWithVersion.class).isPresent(); |
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.
PathWithVersion
does not always contain a version URI; when the original request path does not correspond to a version identifier, eg. when it contains a branch separator character, only an absolute branch path will be returned from the resolver:
Lines 76 to 80 in eb3e28d
final String relativeBranchPath = terminologyResource.getRelativeBranchPath(uriToResolve.getPath()); | |
if (uriToResolve.getPath().contains(Branch.SEPARATOR)) { | |
final String absoluteBranchPath = relativeBranchPath + uriToResolve.getTimestampPart(); | |
return new PathWithVersion(absoluteBranchPath); | |
} |
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 agree, it would be nice to introduce a more rigorous condition for this, given that it is quite hard to validate if a search result is indeed correct when it was cached.
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'm open to any suggestions. This was the easiest way at the moment to determine whether a request is being executed on a version or not (and I think it's not that bad 😅).
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.
@apeteri see this piece of code, the PathWithVersion instance gets injected only when it has a version URI:
https://github.com/b2ihealthcare/snow-owl/pull/931/files#diff-a4877e9655543b6f3a4aeb80fb2df33cfb521470f823c273b36214aad0b087ecR47
* @return whether the search should cache the resulting hits in the underlying index system or not | ||
*/ | ||
protected boolean cacheHits(C context) { | ||
return Revision.class.isAssignableFrom(getFrom()) && context.optionalService(PathWithVersion.class).isPresent(); |
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 agree, it would be nice to introduce a more rigorous condition for this, given that it is quite hard to validate if a search result is indeed correct when it was cached.
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 introduces index-level search request caching and potential configuration on request API level via cacheHits(ServiceProvider).
By default the system will cache: