Option to specify different search methods

[thomasjsn]

I'd like to have the option of using different search/sorting methods for different document types. I'm looking at overriding or expanding the performSearch method.

What would be the best way to accomplish this? Any ideas or pointers to get me started on a possible pull request?

Search methods: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-common-terms-query.html

[huglester]

same here, I do want to port some custom sollution to Scount.

what I want now, is sort like this:

'sort' => [
    [
        'created_at' => [
            'order' => 'desc',
        ],
        'id' => [
            'order' => 'desc',
        ],
    ],
],

is there any option to achieve this at the moment?

[thomasjsn]

It's a bit tricky passing parameters to the engine, because one has to adhere to the Scout engine base class. I have made some changes to the query and filtering, which I think has made the search return better results, and faster. But nothing on sorting, yet...

[thomasjsn]

@huglester You could just fork it and make your own special implementation of course.

[thomasjsn]

@ErickTamayo Hey, I've forked and made some changes to the search query which I think returns much better results, faster.

• Remove asterisk wildcards from beginning and end of query, they make the search slower and make it impossible to use certain boolean operators.

In order to prevent extremely slow wildcard queries, a wildcard term should not start with one of the wildcards * or ?.

• Use default operator AND instead of OR, this returns more relevant results (I think) and is closer to what Algolia returns.

• Apply Scout filters as filter instead of must. This makes it faster and does not change the scoring of the query search results. I've also changed the filter condition from match_phrase to term, which is again faster.

When used in filtering context, the query is said to be a "non-scoring" or "filtering" query. That is, the query simply asks the question: "Does this document match?". The answer is always a simple, binary yes|no.

I've also added a filter to remove results which is not present in the instances of the given model, like the Algolia engine has. That solved issue #36.

Now... The changes I have made to the query will produce different search results, which may produce unwanted results for some. But I think it's a better way of searching. Will you be accepting a PR?

Update 13.feb: I've made the search method configurable in the scout config, and overridable within search searchable model.

[huglester]

Let's hope we will be able to solve this issue ar 'ELasticsearch' level.
It seems that this driver will be kinda out of sync with algolia - but anyway - this ELasticsearch is other world.

[thomasjsn]

I have added the ability to define different search types in the config file, or override them like this:

$articles = Article::elasticSearch('multi_match', $q, [
    'fields' => ['title', 'content', 'tags'],
    'fuzziness' => 'auto',
    'prefix_length' => 2,
    'operator' => 'AND'
])
    ->where('is_published', true)
    ->get();

Using a ElasticSearchable trait, instead of Searchable.

[huglester]

Wow. As for now I think this is exactly what is needed!

SO it does support this 'fluent' syntax like: where('is_published', true)?
this is awesome.

[thomasjsn]

@huglester The where method is just the filter, as is implemented in the driver today. The "fluent" part is the Elasticsearch field name, the Article model has a boolean field called is_published. Very readable :)

I'm planning to submit a PR after I've done some more testing.