Laravel Scout provides a driver based solution to searching your Eloquent models.

Reopened since squashing would include other poeples commits from the upstream sync.

Initial Elasticsearch support, tests on the way.

Some options may differ and I may make a custom config key for customizing the query parameter, Elastic can be really complex but this setup should cover most scenarios.

Working right now:

• Searching
• Searching with where conditions
• Pagination
• Unit Testing :)

TODO:

• For future implementations, for both algolia and elastic, may the performSearch be a replaceable callback,so people can extend and customize it, gonna send a separate PR on it

So basically I deployed my app to production, and I'm having an issue with Scout not importing the records. in a component I have:

var algoliasearch = require('algoliasearch');
var client = algoliasearch('ID', 'KEY');
var = index = client.initIndex('prod_users'); // index i created in algolia with 0 records

my production database has 1 user on my server I run

php artisan scout:import "App\User"

and it says:

Imported [App\User] models up to ID: 1
All [App\User] records have been imported.

but when I look into my algolia dashboard in the indexes section, my prod_users index has 0 records

I've been trying to understand this for some time now, but cannot seem to find a fix. Adding and updating a model to Algolia works just fine. But I cannot remove/delete the user from the Algolia index.

Example: ObjectID = 100, which is the users id. When calling User::find(100)->delete(); the user gets deleted from my app, but remains in the Algolia index. As far as I can see from the docs, this is how it should work, right?

Even calling User::find($userid)->unsearchable(); before deleting the user has no effect on the index.

Engine delete operations, much like update operations, invoke the network and add latency. I would expect Searchable::queueRemoveFromSearch() to optionally use a queue just like Searchable::queueMakeSearchable() does. It even has queue in the name.

A new Job called MakeUnsearchable would also need to be created.

This Pull Request adds the possibility of changing the concrete implementation of the Builder::class. Behind the scenes, the developer can now specify is own implementation doing:

        $this->app->bind(
            \Laravel\Scout\Builder::class,
            \My\Custom\Builder::class
        );

Hi there,

I'm using scout with algolia to index a large database of products, however when trying to sort the results, i'm not getting the desired results.

$products = Product::search('')
                ->orderBy('name', 'asc')
                ->paginate();

Anything i'm missing for this to return results ordered by name?

When trying to set the scout engine to the "null" implementation (e.g. say as a fallback for when no env variable exists: 'driver' => env('SCOUT_DRIVER', 'null') or for tests) the string "null" is parsed into a php null value instead resulting in an instantiation error.

Suggest either renaming the null driver so something else like nullsearcher unless there is a way in phpunit.xml and .env it can be set as a string.

It seems scout:flush doesn't seem to do anything. Deleting a record from the database manually then doing scout:flush and/or scout:import doesn't remove the old record.

Trying a fix against https://github.com/laravel/scout/issues/651

This PR overloads the keys() method in the base Engine class providing MeilisearchEngine the exact Scout key to be used when mapping search results.

Previously the key was determined by taking the first key of the array in the search response. However as recently discovered in the aforementioned issue - Meilisearch will return random array order depending on its index configuration.

• Scout Version: 9.4.6
• Scout Driver: MeiliSearch
• Laravel Version: 8.83.6
• PHP Version: 8.0.16
• Database Driver & Version: Mysql 8.0.28-0ubuntu0.20.04.3
• SDK Version (If using a third-party service): 0.23.1

Description:

This issue is related with https://github.com/laravel/scout/issues/535 and map id with key name, the solution was https://github.com/laravel/scout/commit/8a7782c5ce72b9407a3cb2e29a4865cf4efc964b creating mapIdsFrom method

The same issue is occurring with the method keys in Engine, does not take into account mapIdsFrom and call directly mapIds, which breaks the pagination count.

A solution is create keysFrom method:

/**
     * Get the results of the query as a Collection of primary keys.
     *
     * @param  \Laravel\Scout\Builder  $builder
     * @param  string  $key
     * @return \Illuminate\Support\Collection
     */
    public function keysFrom(Builder $builder, $key)
    {
        return $this->mapIdsFrom($this->search($builder), $key);
    }

and modify the getTotalCount method:

/**
     * Get the total number of results from the Scout engine, or fallback to query builder.
     *
     * @param  mixed  $results
     * @return int
     */
    protected function getTotalCount($results)
    {
        $engine = $this->engine();

        $totalCount = $engine->getTotalCount($results);

        if (is_null($this->queryCallback)) {
            return $totalCount;
        }

        $ids = $engine->mapIdsFrom(
            $results,
            $key = Str::afterLast($this->model->getScoutKeyName(), '.')
        )->all();

        if (count($ids) < $totalCount) {
            $ids = $engine->keysFrom(tap(clone $this, function ($builder) use ($totalCount) {
                $builder->take(
                    is_null($this->limit) ? $totalCount : min($this->limit, $totalCount)
                );
            }), $key)->all();
        }

        return $this->model->queryScoutModelsByIds(
            $this, $ids
        )->toBase()->getCountForPagination();
    }

Changing $key = Str::afterLast($this->model->getScoutKeyName(), '.') and calling $engine->keysFrom reusing the $key variable

Steps To Reproduce:

Using query() reproduce the bug

return Post::search($search)->query(function($query) { $query->with('image'); })->paginate(5);

In a recent project using Scout I wanted to check if a class uses the Searchable trait. Currently this can only be achieved by one of the following options:

// A. check trait usage
if (! in_array(Searchable::class, class_uses($model)) {
    throw new Exception();
}

// B. check method existence
if (! method_exists($model, 'searchableAs')) {
    throw new Exception();
}

• Option A will work, but static analysis will not understand that $model has a specific set of methods.
• Option B does support static analysis, but is messy, because it doesn't really check for the trait (or specific contract).

Therefore I've added a contract to complement the trait.

use Laravel\Scout\Contracts\Searchable as SearchableContract;

if (! $model instanceof SearchableContract::class) {
    throw new Exception();
}

This contract is not required for general use of Scout and is not a breaking change.

wip

TODO:

• [ ] Migration guide
  • [ ] casing of the the client in the service container has been renamed (use the correct \Meilisearch\Client)
  • [ ] minimum required meilisearch-php library version v1
  • [ ] Usage of the new pagination implementation of meilisearch (page/hitsPerPage) which makes the search results exhausitve instead of estimated
  • [ ] No workarounds for earlier meilisearch-php library versions (filters => filter)