[ESRCH-33] Implement mechanism to delegate to concrete search implementation Created: 06/Oct/20 Updated: 03/Feb/21 Resolved: 02/Feb/21 |
|
| Status: | Closed |
| Project: | External Enterprise Search |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.0 |
| Type: | Story | Priority: | Neutral |
| Reporter: | Ilgun Ilgun | Assignee: | Jesus Alonso |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Date of First Response: | |
| Epic Link: | ES indexing POC |
| Sprint: | Add-Ons 53, Add-Ons 54, Add-Ons 55, Add-Ons 56 |
| Story Points: | 8 |
| Description |
|
In the runtime, we need to figure out whether ES is implemented or not.
AC
|
| Comments |
| Comment by Michael Duerig [ 01/Dec/20 ] |
|
One approach could be to reuse the JCR QueryManager. See https://jira.magnolia-cms.com/browse/ESRCH-34?focusedCommentId=241630&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-241630 |
| Comment by Jesus Alonso [ 11/Dec/20 ] |
|
There are some search calls that are triggered directly by JCR. For instance: info.magnolia.enterprisesearch.jcr.EnterpriseSearchQuery.execute(EnterpriseSearchQuery.java:52) at info.magnolia.enterprisesearch.jcr.EnterpriseSearchQuery.execute(EnterpriseSearchQuery.java:52) at org.apache.jackrabbit.core.security.user.IndexNodeResolver.findNode(IndexNodeResolver.java:73) at org.apache.jackrabbit.core.security.user.UserManagerImpl.getAuthorizable(UserManagerImpl.java:504) at org.apache.jackrabbit.core.security.principal.DefaultPrincipalProvider.providePrincipal(DefaultPrincipalProvider.java:125) at org.apache.jackrabbit.core.security.principal.AbstractPrincipalProvider.getPrincipal(AbstractPrincipalProvider.java:112) at org.apache.jackrabbit.core.security.principal.PrincipalManagerImpl.internalGetPrincipal(PrincipalManagerImpl.java:176) at org.apache.jackrabbit.core.security.principal.PrincipalManagerImpl.hasPrincipal(PrincipalManagerImpl.java:67) at org.apache.jackrabbit.core.security.authorization.principalbased.ACLProvider.init(ACLProvider.java:118) at org.apache.jackrabbit.core.security.authorization.combined.CombinedProvider.init(CombinedProvider.java:119) at info.magnolia.cms.core.MagnoliaAccessProvider.init(MagnoliaAccessProvider.java:142) In these cases, as we cannot change the code, we have to keep using JCR queries. I would propose to use JCR indexing & queries for these particular cases. The above example affected the default workspace. |
| Comment by Michael Duerig [ 11/Dec/20 ] |
|
This is one of the cases I mentioned on ESRCH-41. AFAIK this particular case is mitigated by the fact the the JR user manager falls back to traversal if there is no query index. However, I agree that in a first step we need to keep the JCR query capability. Independent of that we could expose "ES" as a supported query language via QueryManager#getSupportedQueryLanguages. In that way ES queries can be run using the QueryManager#createQuery(statement, language) API by passing "ES" for the second argument. Existing JCR queries keep working as long as we keep the Lucene index. |