Elasticsuite: Unable to search by SKU

[robbanl]

I've tried search using SKU with the 2.4.x branch but it's still a no go. No results turn up. From what I've seen there have been other tickets that says they are solved but then commented later on that they do not work.

Magento Version : CE2.1.4
ElasticSuite Version : 2
Environment : both

[southerncomputer]

https://github.com/wardcapp/elasticsuite/commit/2ac9f8e0bf9f05eb038f7e748496072dcf186abd

apply that patch to 2.4.x branch and reindex

[robbanl]

I've tried that but it still won't work. I can see the SKU in the ES index when doing a manual check :(

[southerncomputer]

Works for me i've got 1.5M sku's and it works a-okay!

[romainruaud]

Hello @robbanl

The solution given by @southerncomputer may be dependant of the way your SKUs are "built" ? Are they fully numeric or a mix from letter and numbers ?

Regards

[indiebytes]

Hi @romainruaud,

I work with @robbanl and can tell that the SKUs consist of an mix of letters, numbers and some other characters, at least dashes and underscores.

Thanks for helping out!

[southerncomputer]

It would be nice to allow SKU like search for meta keywords as well, since I end up putting the SKU,MFGPART#,UPC,EAN,GTIN,Competitor part # in that location as well. Easy way to increase matching capacity without increasing too many attributes!

I will say the dash does cause problems since ABC-V1P80 will not match at all whilst V1P80 will match. I just copied romainruaud 's solution from is_reference module.

If you have suggestion on how to match PREFIX-MFGPARTNO with all sorts of garbage in the sku, please let us know! ie HEW-V1P80UTR#ABA which does not get matched very well!

[samc2810]

Is there any solution to this?
The solution of @southerncomputer doesnt seem to work for V2.3.5

[romainruaud]

@samc2810 please give me some examples of SKUs you are using, I will take a look at this one.

Best regards,

[romainruaud]

@indiebytes and @robbanl please provide me some examples of SKU too

[robbanl]

@romainruaud Hi, thank you for this! The SKU's we ( @indiebytes and I ) are using looks like this:

101177BLG
101194
11610018
2153441973
1161122100
FSQ11GY
T856239

[romainruaud]

@robbanl which version of the module are you using ? 2.3 or 2.4 ?

Since this part have been reworked in 2.4 (and therefore, the patch given by @southerncomputer can only be applied to 2.4 version, it has no effect on 2.3).

Regards

[samc2810]

Hi

We are using plain 7 digit numbers

[robbanl]

@romainruaud Currently we're using the dev-master branch of the module, but we've tried lots of different versions previously when trying to fix the issue :)

[southerncomputer]

<filter name="reference_delimiter" type="word_delimiter" language="default">
             <generate_word_parts>0</generate_word_parts>
             <catenate_words>1</catenate_words>
             <catenate_numbers>1</catenate_numbers>
             <catenate_all>0</catenate_all>
             <split_on_case_change>0</split_on_case_change>
             <split_on_numerics>0</split_on_numerics>
             <preserve_original>1</preserve_original>
         </filter>
    </filters>

    <analyzers>

<analyzer name="reference" tokenizer="whitespace" language="default"> <filters> <filter ref="keyword_repeat"/> <filter ref="reference_delimiter" /> <filter ref="lowercase" /> <filter ref="ascii_folding" /> <filter ref="trim" /> <filter ref="edge_ngram_front" /> <filter ref="edge_ngram_back"/> <filter ref="ngram_filter"/> </filters> <char_filters> <char_filter ref="html_strip" /> </char_filters> </analyzer>

`
any better?

[southerncomputer]

Anyone notice auto-complete does a much better job at sku?!

[wardcapp]

@southerncomputer thank you again for your feedback on this!
I bundled the proposed changes into the following commit:
https://github.com/wardcapp/elasticsuite/commit/abb03a2178e57c0d452966524f6d3f1a35eea743

Sadly, after testing these changes on multiple environments (using Elasticsearch server version 2.4.4 and Magento CE 2.1.3), the SKU search is still not fully working (tested using SKU RS-25-48). Although the results are improved greatly (and autocomplete indeed does a better job), it is still not a closing solution.

Hopefully official 2.4 release will contain an answer to this.

[aaronware]

We recently noticed this issue as well in 2.3 with SKU that have a . (period) in them. Is 2.4 a stable for a production environment? I saw the proposed changes from @southerncomputer and I am wondering if there is a difference in . vs - in accuracy. Or if it's any sku that have a non alphanumeric character that have an issue.

[ericrisler]

Latest 2.4 with the wardcapp/elasticsuite@abb03a2 patch applied doesn't seem to help us.

We are using mixed alphanumeric skus without dashes. We decided to log the data sent to ES in by adding file_put_contents(BP.'/var/log/mynt_es_queries.log', print_r(json_encode($searchRequest), true)."\n\n", FILE_APPEND); to the Smile\ElasticsuiteCore\Search\Adapter\Elasticsuite\Adapter::doRequest() method. The result is that a simple search for a sku is sent to ES like so:

{
  "from": 0,
  "size": 0,
  "sort": [{
    "_score": {
      "order": "desc",
      "missing": "_first",
      "unmapped_type": "string"
    }
  }, {
    "entity_id": {
      "order": "desc",
      "missing": "_first",
      "unmapped_type": "string"
    }
  }],
  "query": {
    "filtered": {
      "filter": {
        "terms": {
          "visibility": [3, 4],
          "boost": 1
        }
      },
      "query": {
        "bool": {
          "must": [{
            "multi_match": {
              "query": "BSX20",
              "fields": ["search^1", "sku^1", "name^5", "search.whitespace^10", "name.whitespace^50"],
              "minimum_should_match": 1,
              "tie_breaker": 1,
              "boost": 1,
              "type": "best_fields",
              "cutoff_frequency": 0.15
            }
          }],
          "must_not": [],
          "should": [{
            "multi_match": {
              "query": "BSX20",
              "fields": ["spelling.whitespace^10", "name.whitespace^50"],
              "minimum_should_match": "100%",
              "tie_breaker": 1,
              "boost": 1,
              "type": "best_fields",
              "cutoff_frequency": 0.15,
              "fuzziness": "AUTO",
              "prefix_length": 1,
              "max_expansions": 10
            }
          }, {
            "multi_match": {
              "query": "BSX20",
              "fields": ["spelling.phonetic^1"],
              "minimum_should_match": "100%",
              "tie_breaker": 1,
              "boost": 1,
              "type": "best_fields",
              "cutoff_frequency": 0.15
            }
          }],
          "minimum_should_match": 1,
          "boost": 1
        }
      },
      "boost": 1
    }
  },
  "aggregations": {
    "attribute_set_id": {
      "terms": {
        "field": "attribute_set_id",
        "size": 0,
        "order": {
          "_count": "desc"
        }
      }
    }
  }
}

This results in 0 hits.

However, I noticed that if we change the minimum_should_match in the should clauses (or remove the should clauses entirely) we end up with 120 matches.

{
  "from": 0,
  "size": 0,
  "sort": [{
    "_score": {
      "order": "desc",
      "missing": "_first",
      "unmapped_type": "string"
    }
  }, {
    "entity_id": {
      "order": "desc",
      "missing": "_first",
      "unmapped_type": "string"
    }
  }],
  "query": {
    "filtered": {
      "filter": {
        "terms": {
          "visibility": [3, 4],
          "boost": 1
        }
      },
      "query": {
        "bool": {
          "must": [{
            "multi_match": {
              "query": "BSX20",
              "fields": ["search^1", "sku^1", "name^5", "search.whitespace^10", "name.whitespace^50"],
              "minimum_should_match": 1,
              "tie_breaker": 1,
              "boost": 1,
              "type": "best_fields",
              "cutoff_frequency": 0.15
            }
          }],
          "must_not": [],
          "should": [],
          "minimum_should_match": 1,
          "boost": 1
        }
      },
      "boost": 1
    }
  }
}

Maybe the above helps the community figure this out.

[southerncomputer]

The problem is that getdefaultSearchAnalyzer was removed from the source for some reason, and that patch relies on that functionality! in 2.4 the defaultSearchAnalyzer is all missing!

Btw, have you tried removing 1 character from the left or right, and gotten hits on your sku? I've concluded that is the edge-ngram setting being kind of shy.

All of my sku's are 3-4 letter prefix . ie HEW-MFRPART# so I can search on MFRPART#, or 1 character left missing, or 1 character right missing off the full sku.

[ericrisler]

@southerncomputer -- searching for partials doesn't appear to function on our install either. When you say that the defaultSearchAnalyzer is missing - are you suggesting that the optimizations in https://github.com/wardcapp/elasticsuite/commit/abb03a2 do not properly function? As an FYI, executing http://localhost:9200/<index>/_mapping/product reveals the following structure for the sku field:

"sku": {
    "type": "string",
    "norms": {
        "enabled": false
    },
    "index_options": "docs",
    "fielddata": {
        "format": "disabled"
    },
    "fields": {
        "untouched": {
            "type": "string",
            "index": "not_analyzed"
        }
    },
    "copy_to": [
        "search"
    ],
    "analyzer": "reference"
}

....which would indicate the index is properly built as the analyzer is set to 'reference'.
Could you elaborate on your meaning?
Thanks

[southerncomputer]

https://github.com/romainruaud/elasticsuite/commit/03034400b0b256aac48e649da74ed07cd74d27dd.diff
I patched this in today to 2.4 and added a few more things and I got it to work as expected !

I'm not so hot on posting diff files but you can grab the files I've modded here (reference is a modified version of 2.4)
elasticsuite.zip

after reindexing I can autocomplete on 2+ sku letters and the full search returns almost too many products (need to implement SCROLL ROMAIN!)

here is my sku mapping now!
"sku" : {
"type" : "string",
"norms" : {
"enabled" : false
},
"fielddata" : {
"format" : "disabled"
},
"fields" : {
"reference" : {
"type" : "string",
"norms" : {
"enabled" : false
},
"index_options" : "docs",
"fielddata" : {
"format" : "disabled"
},
"analyzer" : "reference"
},
"untouched" : {
"type" : "string",
"index" : "not_analyzed"
}
},
"copy_to" : [ "search", "spelling", "reference" ],
"analyzer" : "standard"
},
"spelling" : {
"type" : "string",
"fields" : {
"phonetic" : {
"type" : "string",
"analyzer" : "phonetic"
},
"shingle" : {
"type" : "string",
"analyzer" : "shingle"
},
"whitespace" : {
"type" : "string",

that zip file basically does the same as the diff file - but that diff file is for 2.2 -> 2.3 so perhaps you can make a worth diff out of both of my zip and that diff file!

[ericrisler]

@southerncomputer - we are going to try this out - however your zip's inner tgz file appears to contain symlinks and errors out during uncompressing:

x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Setup/
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Setup/InstallData.php
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Setup/UpgradeSchema.php
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Setup/InstallSchema.php
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Setup/UpgradeData.php
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Setup/UpgradeSchema.php: Can't create 'vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Setup/UpgradeSchema.php'
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Helper/Attribute.php
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/etc/elasticsuite_indices.xml
x vendor/smile/elasticsuite/src/module-elasticsuite-catalog/Block/Plugin/Adminhtml/Product/Attribute/Edit/Tab/FrontPlugin.php
x vendor/smile/elasticsuite/src/03034400b0b256aac48e649da74ed07cd74d27dd.diff
x vendor/smile/elasticsuite/src/module-elasticsuite-core/etc/elasticsuite_indices.xml
x vendor/smile/elasticsuite/src/module-elasticsuite-core/etc/elasticsuite_analysis.xml
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/Mapping/
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/Mapping/FieldFilterInterface.php
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/Mapping/DynamicFieldProviderInterface.php
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/Mapping/FieldInterface.php
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/Mapping/FieldInterface.php.orig
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/Mapping/FieldInterface.php: Can't create 'vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/Mapping/FieldInterface.php'
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Api/Index/MappingInterface.php
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Index/Mapping/
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Index/Mapping/Field.php.orig
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Index/Mapping/Field.php.rej
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Index/Mapping/Field.php
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Index/Mapping/Field.php: Can't create 'vendor/smile/elasticsuite/src/module-elasticsuite-core/Index/Mapping/Field.php'
x vendor/smile/elasticsuite/src/module-elasticsuite-core/Index/Mapping.php

Your patch file also failed for us with a fresh checkout of the 2.4.x branch.:

patching file src/module-elasticsuite-catalog/Block/Plugin/Adminhtml/Product/Attribute/Edit/Tab/FrontPlugin.php
Hunk #1 succeeded at 262 (offset -11 lines).
patching file src/module-elasticsuite-catalog/Helper/Attribute.php
Hunk #1 succeeded at 111 with fuzz 1 (offset 1 line).
patching file src/module-elasticsuite-catalog/Setup/UpgradeSchema.php
Hunk #1 succeeded at 47 with fuzz 1 (offset 4 lines).
Hunk #2 succeeded at 102 with fuzz 2 (offset 17 lines).
patching file src/module-elasticsuite-catalog/etc/elasticsuite_indices.xml
Hunk #1 FAILED at 36.
1 out of 1 hunk FAILED -- saving rejects to file src/module-elasticsuite-catalog/etc/elasticsuite_indices.xml.rej
patching file src/module-elasticsuite-catalog/etc/module.xml
Hunk #1 FAILED at 17.
1 out of 1 hunk FAILED -- saving rejects to file src/module-elasticsuite-catalog/etc/module.xml.rej
patching file src/module-elasticsuite-catalog/i18n/en_US.csv
Hunk #1 FAILED at 42.
1 out of 1 hunk FAILED -- saving rejects to file src/module-elasticsuite-catalog/i18n/en_US.csv.rej
patching file src/module-elasticsuite-catalog/i18n/fr_FR.csv
Hunk #1 FAILED at 42.
1 out of 1 hunk FAILED -- saving rejects to file src/module-elasticsuite-catalog/i18n/fr_FR.csv.rej
patching file src/module-elasticsuite-core/Api/Index/Mapping/FieldInterface.php
Hunk #1 succeeded at 47 with fuzz 2 (offset -1 lines).
Hunk #2 succeeded at 91 with fuzz 1 (offset -8 lines).
patching file src/module-elasticsuite-core/Index/Mapping/Field.php
Hunk #1 FAILED at 59.
Hunk #2 succeeded at 137 (offset -2 lines).
Hunk #3 FAILED at 303.
2 out of 3 hunks FAILED -- saving rejects to file src/module-elasticsuite-core/Index/Mapping/Field.php.rej
patching file src/module-elasticsuite-core/etc/elasticsuite_analysis.xml
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 129 with fuzz 2 (offset -17 lines).

The failures appear to be minor so we will attempt ot manually apply the changes and test.

Thanks for the help.

[ericrisler]

@southerncomputer I just noticed your note about the patch - 2.2->2.3 that's why it's failing I'm sure. Can you just re-upload your zip file - I'll create branch and pull request if it appears to work for us.

[ericrisler]

@southerncomputer - so we took the Smile-SA/elasticsuite 2.4.x branch and applied your patch as best as possible. Typing the exact sku appears to return a single result. When we put in a Partial sku like BSX2 the BSX20 product doesn't even appear.

We altered the sku attribute config and enabled the If this field modelizes a reference setting and then reindexed after but our mapping for the sku field is missing a copy_to item:

"sku": {
    "type": "string",
    "norms": {
        "enabled": false
    },
    "fielddata": {
        "format": "disabled"
    },
    "fields": {
        "reference": {
            "type": "string",
            "norms": {
                "enabled": false
            },
            "index_options": "docs",
            "fielddata": {
                "format": "disabled"
            },
            "analyzer": "reference"
        },
        "untouched": {
            "type": "string",
            "index": "not_analyzed"
        }
    },
    "copy_to": [
        "search",
        "spelling"
    ],
    "analyzer": "standard"
},

Of all the changes listed in the path, the only one that didn't resolve well was in the Smile\ElasticsuiteCore\Index\Mapping\Field::getFieldAnalyzers() method. This is what ours looks like now, does it seem correct?

    /**
     * Retrieve analyzers used with the current field depending of the field configuration.
     *
     * @return array
     */
    private function getFieldAnalyzers()
    {
        $analyzers = [];

        if ($this->isSearchable() || $this->isUsedForSortBy()) {
            // Default search analyzer.
            $analyzers = [$this->getDefaultSearchAnalyzer()];

            if ($this->isSearchable() && $this->getSearchWeight() > 1) {
                $analyzers[] = self::ANALYZER_WHITESPACE;
                $analyzers[] = self::ANALYZER_SHINGLE;
            }
        }

        if ($this->isFilterable() || empty($analyzers)) {
            // For filterable fields or fields without analyzer : append the untouched analyzer.
            $analyzers[] = self::ANALYZER_UNTOUCHED;
        }

        if ($this->isUsedForSortBy()) {
            $analyzers[] = self::ANALYZER_SORTABLE;
        }

        if ($this->isReferenceField()) {
          $analyzers[] = self::ANALYZER_REFERENCE;
        } elseif ($this->isUsedInSpellcheck()) {
          // Append phonetic analyzer only if the field is not used to represent a reference.
          $analyzers[] = self::ANALYZER_PHONETIC;
        }

        return $analyzers;
    }

[southerncomputer]

what i meant was to apply the patch as best as possible and then throw the files i put in the zip file on top!
i'll re-zip them since github doesn't accept tarballs!

elasticsuite.zip

how is your sku product attribute set up btw?

[southerncomputer]

btw I have a composite dump analyzed as reference too! I forgot:

"meta_keyword" : {
"type" : "string",
"norms" : {
"enabled" : false
},
"fielddata" : {
"format" : "disabled"
},
"fields" : {
"reference" : {
"type" : "string",
"norms" : {
"enabled" : false
},
"index_options" : "docs",
"fielddata" : {
"format" : "disabled"
},
"analyzer" : "reference"
}
},
"copy_to" : [ "search", "spelling", "reference" ],
"analyzer" : "standard"
},

for instance: hp desktop sku is hew-p5v81ut#aba

has meta_keyword of:
desktop computers hp p5v81ut#aba 1033221449 3l5149 9554cc 43211507 889894971296 12051972 p5v81ut 1183zm 4473033 p5v81utca 0889894971296 5620172 478298 1245741 hp business desktop prodesk 400 g3 desktop computer intel core i5 6th gen i5-6500 3.20 ghz 8 gb ddr4 sdram 1 tb hdd windows 7 professional 64-bit english upgradable to windows 10 pro small form factor dvd-writer dvd-ram/±r/±rw intel hd graphics 530 graphics english keyboard 8 total usb ports WEEE EU WEEE RoHS IT Eco Declaration Ecolabel REACH ENERGY STAR ProDesk 400 G3 Small Form Factor PC (ENERGY STAR) Business Desktop ProDesk 400 G3 Desktop Computer Yes

with autocomplete I can type in HEW-p5v ...#ABA and get hits on all sorts of products, I can also start with P5V... and get hits on various products. I'm not sure if the meta_keywords reference field is affecting autocomplete or not!

I just did romain's 2.2 patch against 2.4 and fixed it up today in my dev environment which doesn't have enough ram to handle the 1+million results that come back due to complex matching that has started working today.

Might need to reduce the sensitivity since I feed Related-products (product family and brand ) back into elasticsearch to auto-generate related proudcts (it works!) but the number of results has gone up since this patch happened!

[southerncomputer]

I had to patch this file as well to deal with 1.5 million product sku's with short sku matching as it is now!

vendor/smile/elasticsuite/src/module-elasticsuite-core/Search/Adapter/Elasticsuite/Request/Aggregation/Builder/Histogram.php: $aggParams = ['field' => $bucket->getField(), 'interval' => $bucket->getInterval(), 'min_doc_count' => 1]; //$bucket->getMinDocCount()];

[ericrisler]

O-K - @southerncomputer - I've applied the patch and updates by diff'ing and manually merging your files and tested locally. Search by Sku (after updating the SKU attribute settings in the admin) works great now. Added all this to Pull Request https://github.com/Smile-SA/elasticsuite/issues/479

[ericrisler]

Hmm, so the saga continues...we have a sku 0064314 in the catalog, but when we search for "64314" the only match is an incorrect but similar sku of "66314".

Perhaps this is the ngram settings - Any suggestions @southerncomputer ? You seem to know whats going on internally. :)

[southerncomputer]

autocomplete or recommended search terms seems to be more accurate? than press-enter search?

I had to increase the minimum ngram size to 3 to deal with the massive assortment of sku.

[southerncomputer]

min ngram 2:

curl -XGET 'localhost:9200/magento2_default_catalog_product_20170728_111205/_analyze?analyzer=reference&?pretty' -d '0064314' |more

{"tokens":[{"token":"0","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"0","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"00","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"6","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"06"
,"start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"006","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"4","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"64","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"064","start_offset":0,"e
nd_offset":7,"type":"word","position":0},{"token":"0064","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"3","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"43","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"643","start_offset":0,"end_offset":7,"type"
:"word","position":0},{"token":"0643","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"00643","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"1","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"31","start_offset":0,"end_offset":7,"type":"word","position
":0},{"token":"431","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"6431","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"06431","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"006431","start_offset":0,"end_offset":7,"type":"word","position":0},{"toke
n":"4","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"14","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"314","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"4314","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"64314","start_o
ffset":0,"end_offset":7,"type":"word","position":0},{"token":"064314","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"0064314","start_offset":0,"end_offset":7,"type":"word","position":0}]}

min ngram 1:
curl -XGET 'localhost:9200/magento2_default_catalog_product_20170726_130558/_analyze?analyzer=reference&?pretty' -d '0064314' |more

{"tokens":[{"token":"006","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"064","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"0064","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"643","start_offset":0,"end_offset":7,"type":"word","position":0},{"tok
en":"0643","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"00643","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"431","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"6431","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"06431","
start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"006431","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"314","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"4314","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"64314","start_offse
t":0,"end_offset":7,"type":"word","position":0},{"token":"064314","start_offset":0,"end_offset":7,"type":"word","position":0},{"token":"0064314","start_offset":0,"end_offset":7,"type":"word","position":0}]}

maybe try

`
0
0
1
1
0
0
1

    <filter name="edge_ngram_front" type="edgeNGram" language="default">
            <min_gram>1</min_gram>
            <max_gram>15</max_gram>
            <side>front</side>
            </filter>
    <filter name="edge_ngram_back" type="edgeNGram" language="default">
            <min_gram>1</min_gram>
            <max_gram>15</max_gram>
            <side>back</side>
            </filter>

`

[ericrisler]

That appears to have made an improvement - thanks again for all the help @southerncomputer

[madonzy]

I still can't understand what should I do to search by SKU like: "NAN-0003-1", I use Elasticsuit 2.3.8 and Magento 2.1.9, ElasticSearch 2.4.6. Any ideas?

[madonzy]

@southerncomputer I've merged your zip and now it works, but it searches only by full SKU, is it possible to make it work like: "FF-32" and it'll find products with SKU: "FF-32123", "FF-32435", "GBFF-32123"?

[afoucret]

We deliver a new patch on the branch 2.4.x.
This should fix the search by sku problem this time.

Feel free to test the 2.4.x branch and reopen if not fixed.

[wardcapp]

Just in case others would like to add a patched 2.3.x version of the module to their Magento 2.1.x installation as well, a forked repository with a custom 2.3.12 release (containing the corrected SKU search) is available at https://github.com/studioemma/elasticsuite/releases/tag/2.3.12.

I was able to test the SKU's RS-25-24 and RS-25-48 with success ony my local environment (confirming the patch is working), so thanks again @romainruaud and @afoucret for the great support!