там все сложно...)))

нах#евертили что надо)

Не работает, ибо аргументы для команды передаются массивом отдельно, а не в строке

Доброго дня, так пробував теж, хоча в доках написано, що можна й в одну стрічку.

Варіант Artisan::call('aimeos:jobs', ['jobs' => 'product/import/csv', 'site' => 'smartshop']) теж результату не дає.

Якщо туди підставити якусь рідну команду, наприклад make:controller MyController, то відпрацьовує як треба.

Всем привет. Столкнулся с проблемой при создании поиска по сайту. Ищу по 3 моделям. Грубо Блог посты, FAQ и документы. Хочу выдавать по дате . Плюс модели все разные по столбцам. Соответственно делаю промежуточную коллекцию, добавляя туда результаты поиска и формирую что-тот типа заголовка и краткого описанию сущности которая найдена. Приделал пагинатор, который правда пока не передает в ссылках поисковую query строку. Но главная проблема в другом. Получается каждый раз сервер будет искать в 3 таблицах при пагинации . Потребление памяти будет жестким и я не могу ограничить конкретный запрос к модели, потому что у меня общий пагинатор. Может кто-то подскажет варианты решения?

можешь попробовать сделать на основе mysql view и по ней искать и пагинатор будет работать

еще не сталкивался. это переложить работу на мускл и забрать ее у laravel scout ?

scout умеет неточный поиск делать

ты же не уточнял как у тебя поиск организован :)

я вот так решил похожую задачу:

   $total = count($items);
$page = $page ?: (Paginator::resolveCurrentPage() ?: 1);


   $items = $items->forPage($page, $per_page)->flatten();

   return new LengthAwarePaginator($items, $total, $per_page, $page);

это решение не теряет строку поиска ?  метода get у меня

читаю про mysql views. There's also a caveat to using views though. Depending on the kind of query, MySQL will need to construct an "in memory" table representing the view, at runtime. This operation is called table materialization and happens when using certain keywords like GROUP BY, or aggregated functions.

The takeaway is that views might actually hurt query performance, depending on the kind of query you're executing.

сделал поиск по таблицам смержил всё в один оьект, прошелся мапом, сформировал общий вид и добавил тот кусок кода что кинул

это стандартное решение в ларе, страницы работают без проблем

поведение такое же как ->paginate()

Вот этот момент и пугает меня. Представим гипотетически, что по поиску получаются миллионы строк в каждой таблице. Например ищем по 2 буквам. Мы должны закинуть все это в память и смержить. Если бы бы поиск по одной модели - у нас есть LIMIT для мускла

А так на каждом запросе пагинации идет выгрузка в память всех строк

никкого limit

думаю что прямого решения и нет. это же чисто физическая проблема

ну тут ка бы я вижу 2 путя. Первый это промежуточная таблица с теми полями по которым идет поиск, в подробности розписывать не буду. Второй вариант это при поиске сразу лимитировать, например по per_page