EZP-30282: Impl. indexing of related objects for the full text search

[adamwojs]

JIRA: https://jira.ez.no/browse/EZP-30282

Description

Impl. indexation of related objects for the full text search.

Indexing related content

Text of related content is stored in the meta_related_content_X__text_t index fields where X is relation level e.g. meta_related_content_1__text_t, meta_related_content_2__text_t

Boost factor for related content

As an User, I expect the following order of search results for query "Content A": Content A, Content B when content repository contains Content A and Content B with embedded Content A.

This is implemented by adding boost factor based on the following formula:

to the index fields with related content. Ref.

ezplatform-solr-search-engine/lib/Query/Content/CriterionVisitor/FullText.php

Lines 154 to 157 in 1238c57

	private function getBoostFactorForRelatedContent(int $depth): float
	{
	return 1.0 / pow(2.0, $depth);
	}

Indexing depth configuration

As a Developer, you are able to define the maximum indexing depth using the following YAML configuration:

ez_search_engine_solr:
    # ...
    connections:
        default:
            # ...
            indexing_depth:
                default: 1          # Default value: 0 - no relation indexing, 1 - direct relations, 2nd level  relations, 3rd level  relations (maximum value).
                content_type:
                    article: 2      # Index depth defined for specyfic content type

Indexing of the related content is disabled by default, however, this might change in eZ Platform 3.X.

Checklist:

• Coding standards ($ composer fix-cs)
• Impl. feature / bugifx
• Impl. tests
• Ready for Code Review

[andrerom]

New comment after looking at the updated diff 😄

Looks promising 👍
Would it make sense to only allow depth of 0-3? Also it seems we might need some recursion protection here (content1 -> content2 -> content1 or more advanced circular relations, mainly skipping content1 being indexes several times in the index)

[andrerom]

Somewhat side here:

I'm wondering if this is maybe overlapping with the index boosting issue we have for fields that is being discussed with @kmadejski and @pspanja.

As in to add context on that; From my understand we either need to A. start to index all fields separately for fulltext in order to be able to boost them separately, or B. we need to consider using Solr Payloads in order to be able to boost terms.

If A, then this stuff could have been indexed as part of the relevant relation/relationList/page field full text index. But that said I realize it does not match needs for embeds on RichText which then will need either separate field or Payload as well... :)

---

So in the end, I guess I'm 👍 on the approach here for relations, just wanted to share in case others here look at it differently.

[kmadejski]

Seems to be some copy-paste mistake 😉

[alongosz]

This feels like a rocket science to me. Formula for this is not documented anywhere in Solr.
I'm fine with new inventions, but some Search integration test would be useful to see what it does (especially that you yourself have put implementing tests in TODOs ;) )

But the "request changes" is for something else:

[alongosz]

From my side, after internal discussion, this is fine 👍

[micszo]

Tested successfully depth 1,2,3 with single, shared and multi core setup.
Works fine. 👍