We’re having a problem with the sorting when using the ProductService.SearchService.Search. We’re sorting the result by name by adding this to the QueryRequest.Sortings.
new Sorting("_name".GetFieldDefinitionForProducts().GetTagName(CultureInfo.CurrentUICulture), SortDirection.Ascending, SortingFieldType.String)
The strange behavior is that some, not all, of our products starting with a “W” ends up first in the sorted list. A couple of times this also include some, again not all, products starting with a “V”. After these the rest of the products are sorted correctly in alphabetical order including the rest of the once starting with a “W” or a “V”.
Which of the products starting with “W” or “V” that end up first varies and they are not sorted in alphabetical order individually. What triggers the change of which products that ends up first is rebuilding the products index from backoffice. When a rebuild of the index is done the products ends up first again and the order of them has changed.
If we change any field on these products and save them they are sorted correctly amongst all other products. But as soon as we rebuild of the index from backoffice again they will once again end up first in the sorted list.
Adding another leading letter to the product name of these products will make them be sorted correctly even after a rebuild of the index. However adding another “W” making it “WW…” does not work but adding “W-” making the name “W-W…” is working. Casing does not seem to matter.
Also - we have another field on the products containing a shorter version of the product name. Sorting by this field works perfectly. Problem is that the ShortName field might be empty on some products whereas the _name field is always populated.
Anyone who have any idea on what may cause this strange behavior?
We’re working on an upgrade from Litium 7.4 to 7.6 and the problem occurs in both versions.
Have tried to reproduce the issue but so far the sorting has worked, been testing in 7.6.1 using this sample with different sortings and some different product names:
var sorting = new Sorting(TagNames.Name, SortDirection.Ascending, SortingFieldType.String);
const string culture = "en-US";
var request = new QueryRequest(new CultureInfo(culture), ProductCatalogSearchDomains.Products);
request.ReadTags.Add(TagNames.Name);
request.Sortings.Add(sorting);
request.FilterTags.Add(new Tag(TagNames.AssortmentSystemId, new Guid("9ef8b3c8-432b-49d7-aaf7-efd5f88c3464"))); // At least one tag is required
var result = _searchService.Search(request);
var productNames = result.Hits.Select(hit => hit.Tags.FirstOrDefault(tag => tag.Name.Equals(TagNames.Name + culture))?.Value);
this.Log().Debug($"Hits sorted by {JsonConvert.SerializeObject(sorting)}:\n{string.Join("\n", productNames)}");
OK, I’ll try that. I’ve tried sort by the TagNames.Name before but that gave me the products in a total random order. From what I could see then was that that sorted by the “Searchengine optimized title” field and we’re not using that. I’ll check that again.
Note that we’ve not built our solution on the Litium Accelerator but i guess that shouldn’t make any difference using SearchService, right?
OK, I’ve tried a bunch of different things now. Looks like we were missing the FilterTag for AssortmentSystemId. Adding that don’t make any difference though. Results are as below.
7.6.1 (we’re planning a release of the upgrade in a couple of weeks)
Sorting by TagNames.Name is working. I might not have tried that on 7.6.1 earlier. (Bug in earlier version?)
Sorting by _name still gives the strange behavior described above. Now I even managed to get a product starting with “T” to get first in the result. But like before it’s random which products that ends up first. Almost every time it’s products starting with “W” and it changes after rebuilding the products index.
7.4.3-patch-2009172214 (this is what we’re running on production at the moment)
Sorting by TagNames.Name gives a result with the products in total random order according to their name. Was this a bug in this Litium release?
Sorting by _name gives the same result as before. No change.
We want to release a hotfix for the sorting but I guess we’ll have to wait and include it in the upgrade to 7.6.1 release.
I noticed something though. As I mentioned before we have another field, ShortName, that works perfectly to sort by. The _name field is a MultiLanguage field but the ShortName field is not. Do we need to do something different when adding the sorting if the field is a MultiLanguage field?
new Sorting("_name".GetFieldDefinitionForProducts().GetTagName(CultureInfo.CurrentUICulture), SortDirection.Ascending, SortingFieldType.String) - gives strange behavior.
new Sorting(“ShortName”.GetFieldDefinitionForProducts().GetTagName(CultureInfo.CurrentUICulture), SortDirection.Ascending, SortingFieldType.String) - work perfectly.
The filtertag for Assortment is not needed, I used it in my test just since search require at least one tag.
I am not aware of any sorting bug in your version, but I would not recommend staying on a prerelease when the tested actual release is out (in your case 7.5 is the release of your 7.4.3 prerelease, just version number adjustment from .4 to .5.), and there is not much changed to 7.6.1 so if you have verified that it works in that version it is probably a good solution to upgrade.
We only use one culture so that shouldn’t be the problem. I did a test and hardcoded the culture and used that in all adds and so on where a culture is needed but it made no difference.