Configure Solr¶
Configure boosting¶
Index time boosting
Index time boosting was deprecated in Solr 6.5 and removed in Solr 7.0. Until query time boosting is implemented, there is no way to boost in the bundle out of the box.
How boosting interacts with Search API
Boosting of fields or documents affects the score (relevance) of your search result hits when using Search API for any Criteria you specify on $query->query
, or in REST by using Query
element.
When you don't specify anything to sort on, the result is sorted by this relevance.
Anything set on $query->filter
, or in REST by using Filter
element, doesn't affect scoring and only works as a pure filter for the result.
Thus make sure to place Criteria you want to affect scoring on query
.
Boosting currently happens when indexing, so if you change your configuration you need to re-index.
Boosting tells the search engine which parts of the content model have more importance when searching, and is an important part of tuning your search results relevance.
Importance is defined by using a numeric value, where 1.0
is default, values higher than that are more important, and values lower (down to 0.0
) are less important.
Boosting is configured per connection that you configure to use for a given repository, like in this config/packages/ibexa_solr.yaml
example:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
The configuration above results in the following boosting (content type / Field):
article/title: 2.0
news/description: 1.0
(default)article/text (meta): 5.0
blog_post/name (meta): 10.0
article/name (meta): 2.0
How to configure boosting on specific fields
Currently, boosting on particular fields is missing. However, it could be configured using 3rd party Novactive/NovaeZSolrSearchExtraBundle in case of custom search implementation, for example, to handle your front-end search form. Unfortunately, this doesn't affect search performed in the administration interface.
The following example presents boosting configuration for Folder's name
and description
fields.
First, in ibexa_solr.yaml
configure custom fulltext fields.
1 2 3 4 5 6 7 8 |
|
The second step requires you to use \Novactive\EzSolrSearchExtra\Query\Content\Criterion\MultipleFieldsFullText
instead of default \Ibexa\Contracts\Core\Repository\Values\Content\Query\Criterion\FullText
.
The following example shows custom query which benefits from the custom fields created in the previous example.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
|
Remember to clear the cache and perform search engine reindex afterwords.
The above configuration results in the following boosting (content type / field):
folder/name: 20.0
folder/description: 10.0
Index related objects¶
You can use indexation of related objects to search through text of related content. Indexing is disabled by default. To set it up you need to define the maximum indexing depth using the following YAML configuration:
1 2 3 4 5 6 7 8 9 10 11 |
|
Configure Solr Replication (master/slave)¶
Note
The configuration below has been tested on Solr 7.7.
Configure Master for replication¶
First you need to change the core configuration in solrconfig.xml
(for example */opt/solr/server/ibexa/collection1/conf/solrconfig.xml
).
You can copy and paste the code below before any other requestHandler
section.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Then restart the master with:
1 |
|
Configure Slave for replication¶
You have to edit the same file on the slave server, and use the code below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Next, restart Solr slave.
Connect to the Solr slave interface (http://localhost:8983/solr), go to your core and check the replication status:
Configure HTTP Client for Solr queries¶
Ibexa Solr Bundle uses Symfony HTTP Client to fetch and update Solr index. You can configure timeout and maximum number of retries for that client using Solr Bundle's Semantic configuration:
1 2 3 4 5 6 |
|
Extend Solr¶
To learn how you can create document field mappers, custom Search Criteria, custom Sort Clauses and Aggregations, see Search extensibility.