Have you thought about the pagination?

[tisuchi]

Definitely it's one of the best packages. A big clap for that.

But I cannot see any kinds of pagination option there. The pagination option is important because normally there are a hundred or thousand results in the search.

[nanadjei]

Trying to call pagination on the SearchResults...

Method Spatie\Searchable\SearchResultCollection::paginate does not exist.

[nhayder]

i'm having same issue in my app, is there is a fix for how to paginate searchResults yet ???

[Acen]

It looks like the main issue is with the ModelSearchAspect not returning a Builder Query, but a finalised Collection.
We could just overload the getResults method and return the Builder, rather than the get() returning a Collection. Then from there paginate() would be available.

With that though, we'd then need to overload the search and perform methods to return the Builder from previous.

But then, you might get malformed results due to different model results. Hmm, you start erring on the side of returning dangerous data if you try malforming the data to return a plain data type.

See: https://github.com/spatie/laravel-searchable/blob/master/src/SearchResultCollection.php

[freekmurze]

I don't really see a good way of supporting pagination. When searching different models, how would go about this?

[olineup]

I haven't found a decent solution for pagination while searching different models and ended up using union.

Something like this:

$users = User::select('user.id', 'name', 'email')
    ->addSelect(DB::raw("'users' as type,"))
    ->where('name', 'LIKE', '%' . $search . '%');

$posts = Post::select('post.id', 'title as name')
    ->addSelect(DB::raw("null as email, 'posts' as type"))
    ->where('title', 'LIKE', '%' . $search . '%');

return $users->union($posts)->paginate(5);

And if related data needed then maybe somewhere in Controller/Service/JsonResource additional requests to fetch that data can be made:

public function toArray($request)
{
    return [
        'id' => $this->id,
        'name' => $this->name,
        'type' => $this->type,
        'userPostsCount' => $this->when($this->type === 'users', User::find($this->id)->posts()->count())
    ];
}

Awful, but for me it was better than go without pagination. Maybe will be useful to someone, cos it’s not so easy to find even bad solutions to this problem.

[rcubitto]

How about something like this:

$search = (new Search())
    ->registerModel(User::class, 'name', 'email')
    ->registerModel(Post::class, 'title')
    ->withPagination(15)
    ->search($search);

Behind the scenes, it paginates each group individually.

For example, if we have 5 users and 20 posts:

page 1 ... 5 users & 15 posts
page 2 ... 0 users & 5 posts

We are already grouping results by type, so why not paginate each group?

[jimuelpalaca]

I got some solution for the pagination, but it doesn't solve this problem and doesn't improve the performance. Basically, I just implement a custom pagination using the LengthAwarePaginator.

public function paginate($perPage = 15, $page = 1, $routeName = 'api.search.index')
{
        $results = collect($this->searchResults)->slice(($page - 1) * $perPage, $perPage);

        $paginator = new LengthAwarePaginator($results, count($this->results), $perPage, $page);

        $paginator->setPath(route($routeName));

        return $paginator;
}

[AlexVanderbist]

Hm, preferably we'd want a way to support the same range of options for pagination as Laravel does. Not sure if we can implement some kind of interface that'll make this possible (with keeping multiple model in mind)

When searching different models, how would go about this?

Maybe we can paginate the first n results of each model and just combine them? That'll result too many results but at least they're paginated?

[thewebartisan7]

I handle pagination with offset() and limit() on get results and seem works fine.
The only thing that I don't have is pagination links, but I add one link Load more results which just increase the page number and load second set of data (using infinite scroll the link get even hidden and new results are shown immediately on scroll down)

In getResults instead of ->get():

        return $query->offset(((request()->get('page', 1) - 1) * 100))->limit(100)->get();

I test with two models and seem works fine, on first page I can see both models, on second page only records of one model, and in third no records as expected.

I tested also solution with pagination of collections, but as someone already said, it make things slow on large result.

I am thinking about how to maybe combine both, where limit/offset are very large like 1000 and then use collection for pagination, with 1000 items is not so slow.

What you think?

[WalrusSoup]

The issue I see with the offset is when searching multiple aspects it cannot guarantee a page will end up with the correct number of results. ModelSearchAspect.php is responsible for building the query, so when multiple are used you potentially end up a situation where a paginator of length 50 would return 25 from one aspect and zero from another.

I think for this case, offering pagination via a single search aspect would be possible.

I added a simple version that offers pagination via a single aspect.

You'd need to handle tracking the current page yourself though. Not sure if this is in the spirit of this library to add it, though. Feels like it kind of breaks the flow of what this library is doing. Will need to wait for the author to chime in if this is worth adding or not.

[thewebartisan7]

you potentially end up a situation where a paginator of length 50 would return 25 from one aspect and zero from another

Why should be a problem with simple pagination where there is only prev and next? The number of items will not be the same always, but each query will return the next set of items, with different number of items.

[WalrusSoup]

I don't think having paginators return anything less than their page size (unless they are on the last page, of course) is a good idea.

If I thought I could do it elegantly... Maybe let the previous aspect return it's amount of results and use that to adjust the limit of the next aspect to return (limit + extra) to reach the pagination page size required? Sounds messy though. Not sure. Will sleep on it.

[thewebartisan7]

Yes I think also the same, but it can become easy nightmare to manage, especially when you add new model. I just want to solve issue when there are many results, which make page slow down. I don't think there is an elegant solutions to handle this. I research into and I see some solutions that use UNION or create one single table with polymorphic relations. You can find maybe a solution for your project but make something easy to add new model without changing code is hard, if not impossible.

I also check solution implemented by algolia extended, using aggregator, see https://github.com/algolia/scout-extended but seem they also create one single index like using single polymorphic relations.

I found also this one https://github.com/protonemedia/laravel-cross-eloquent-search, didn't check into because support only mysql, while I am using postgre, but seem it's using UNION, not sure.

[MakamuEvans]

I don't really see a good way of supporting pagination. When searching different models, how would go about this?

What about having the option of paginating one of the specified models?

[simplyniceweb]

still no solution for this? or no plan at all?

[sezohessen]

another solution !
use this package