New answers tagged indexing
0
Solr 6.5 and above does not support index time boosting. See https://issues.apache.org/jira/browse/LUCENE-6819. You can include the boost parameter while indexing, as Sitecore does, and it is simply ignored by Solr.
0
Mark's approach works well for Sitecore 9.1, but not for earlier versions of Sitecore where the ICloudSearchProviderIndexName interface has not been introduced yet.
This blog post (also referenced in Mark's blog post) describes a different solution for Sitecore 9.0.x, based on the implementation of a custom CloudSearchProviderIndex class where the index ...
0
I was able to get some code working to do this on Sitecore 9.1 as per my blog, however I haven't investigated any other Sitecore versions.
General approach is to override the ICloudSearchProviderIndexName with your implementation and then patch in this implementation via config.
public class CloudSearchProviderIndex : Sitecore.ContentSearch.Azure....
-1
Instead of renaming, you should be able to create separate azure indexes for separate environments.
e.g. sitecore-master-{siteName}-{envName}-index
While fetching the search results, siteName and envName come from Sitecore configuration settings to ensure correct index is being referred in azure functions.
0
You can try by copying the field from "name" to a new field
https://lucene.apache.org/solr/guide/6_6/copying-fields.html
This might help.
(edit:trailing character removed from url)
1
Item name (_name) field in lucene/solr is defined as text type, so it is stored as a tokenized value in search indices. So when you search using name, (query will be formed like _name:(alumni)) it will return all items which contains "alumni" in name.
By default, Name/_name is a tokenized field so the result you are getting is absolutely valid/expected.
0
Our final fix for this was around the way we retrieved data from the index.
We simply used the predicate:
searchQuery = searchQuery.Or(q => q.Subtitle == searchTerm);
Instead of:
searchQuery = searchQuery.Or(q => q.Subtitle.Contains(searchTerm));
With Azure the '==' operator in a predicate doesn't behave how you might think it would (or at least ...
1
It looks like the code that decides if a contact should be indexed is defined in the contacts pipeline in the analytics.aggregation pipeline group. Specifically, the default processor is Sitecore.ContentSearch.Analytics.Aggregators.ContactChangeContactAggregator, which just checks contact.ShouldBeIndexed(), which in turn just checks if it is an anonymous ...
Top 50 recent answers are included
