[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

  • Delegate to ES when it is installed
  • Delegate to JCR when it not installed


 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.

Generated at Mon Feb 12 01:55:36 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.