Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filtering product collection by exact SKU returns wrong results when SKU contains special characters #1381

Closed
diwipl opened this issue Apr 17, 2019 · 3 comments
Assignees

Comments

@diwipl
Copy link

diwipl commented Apr 17, 2019

\Smile\ElasticsuiteCatalog\Model\ResourceModel\Product\Fulltext\Collection is not filtering collection properly when SKU condition is used and passed SKUs contain special characters

This might be related to changes done in SKU searching described in wiki:
https://github.com/Smile-SA/elasticsuite/wiki/SearchingBySkuBasics
https://github.com/Smile-SA/elasticsuite/wiki/SearchingBySkuDetailled

Nevertheless filtering itself should not be affected and should return correct results when exact SKUs are provided.

Preconditions

  • Magento 2.3.1 installed with ElasticSuite 2.7.6 and Magento sample data.

Magento Version : 2.3.1

ElasticSuite Version : 2.7.6

Environment : Developer

Steps to reproduce

ObjectManager is used directly only to simplify reproduction.

<?php
        $collection = \Magento\Framework\App\ObjectManager::getInstance()
            ->create( \Smile\ElasticsuiteCatalog\Model\ResourceModel\Product\Fulltext\Collection::class);

        $skus = ['24-MB01', '24-MB04'];
        
        $collection->addFieldToFilter('sku', ['in' => $skus]);
        $products = $collection->getItems();

Expected result

  1. Two entities should be returned by getItems method

Actual result

  1. Empty array is returned
@romainruaud
Copy link
Collaborator

Yes it's actually due to the fact that using in will result in a terms query : https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-term-query.html

Please pay attention to the "Why doesn’t the term query match my document?" part especially.

Since the sku field is analyzed during indexing, it's impossible to match it with a term query if it contains dashes.

From what I can see, there is an easy workaround : just set the sku field to isFilterable via the elasticsuite_indices.xml file, like this :

<indices xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="urn:magento:module:Smile_ElasticsuiteCore:etc/elasticsuite_indices.xsd">

    <index identifier="catalog_product" defaultSearchType="product">
        <type name="product" idFieldName="entity_id">
            <mapping>
                <field name="sku" type="text">
                    <isFilterable>1</isFilterable>
                </field>
...

This will allow you to match with the in condition you described. (I tested and it's working, as it does generate a term query on the sku.untouched field, allowing exact matching).

Actually I'm not sure if we should add this behavior to the Core of ElasticSuite or if it's up to people to decide if they want to use this.

@rbayet any opinion ? I do not fully measure if indexing the untouched version of SKU would collisionate with your recent work on SKU search.

Regards

@rbayet
Copy link
Collaborator

rbayet commented Apr 26, 2019

Hi @romainruaud,

No basically, for correct exact value filtering, the sku should indeed be declared as filterable so its mapping inherits the untouched subfield.
I have no issue with that, the only impact would be the index size.

It will not affect what I described in https://github.com/Smile-SA/elasticsuite/wiki/SearchingBySkuBasics and https://github.com/Smile-SA/elasticsuite/wiki/SearchingBySkuDetailled, the untouched subfield is never a target in the context of a fulltext search for any field whatsoever atm, so it will not impact SKU search.

Regards,

@romainruaud
Copy link
Collaborator

Sounds good to me, so PR #1396 will fix this issue.

Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants