условно.
паттерн
приложение, сборник запросов, "паттерн репозиторий", конкретная реализация обращений к конкретной базе данных
не паттерн
приложение, сборник запросов

в первом случае вы наворачиваете кучу абстракций, зато в любой момент можете переключить базу данных на другую (мы ведь так раз в неделю минимум делаем). к примеру раньше брали данные из мускула, теперь стали брать из редиса. или из файла, или по апи стучать
во втором случае вы просто обращаетесь к елке.

lingohub?

👋 привет всем.
Нужен спец по ларавелу на проект.

Довести до ума платформу по онлайн обучению, отзовитесь в лс😇

Ребята, вопрос по поводу Subscribe в Redis на Laravel. Создал комманду в которой выполняю Subscribe на событие. Каким образом реализовать что бы у меня supervisor который запускает эту команду перезапускал её при изменении файлов скрипта? Для очередей есть команда php artisan queue:restart, а вот как быть с моим случаем?

перезапуск стоит организовать на этапе выгрузки, например взять за основу horizon и при deploy выполнять команду php artisan horizon:terminate
а для выгрузки рассмотри Envoy, например вот с таким простым сценарием:

@servers(['web' => ['1.1.1.1']])

@task('deploy', ['on' => ['web']])
php artisan down
git pull
php artisan migrate --force
composer install --no-dev
php artisan optimize
php artisan view:cache
php artisan horizon:terminate
php artisan up
@endtask

У меня есть jenkins, при деплое, я могу в нём прописать без труда horizon:terminate и это будет перезапускать процессы supervisor'а от horizon очереди. Но мне не понятное другое, каким образом к этому мне привязать команду php artisan redis:subscribe, что бы она перезапускалась в этот момент тоже?

Сейчас я для команды php artisan redis:subscribe создал отдальную конфигурацию в supervisor, которая создаёт и контролирует запущенность этого процесса, мне кажется этот подходит не подходящим, вопрос как можно по другому вызывать и контролировать этот процесс?

нужно в команде с периодичностью проверять некий ключ в redis, если в какой-то момент он изменился, значит нужно умереть, а supervisor поднимет заново, как вариант, отправлять в redis текущую версию приложения, и если с последнего обращения к redis что-то изменилось завершать цикл, что бегает в  redis:subscribe

по аналогии как перезапускаются очереди

беда в том что в redis:subscribe такой код:
public function handle() { Illuminate\Support\Facades\Redis::subscribe('канал', function($message) { .... }) }

Соответственно здесь нету цикла, это код с пример с документации, и как его переделать на цикл?

ты же подписался на событие от redis, в функции замыкания и проверяй на изменение ключа, или по аналогии подпишись на изменение значения, но тут я тебе не подскажу, т.к. не знаком Facades\Redis::subscribe()

Аааа.... Всё понял, словил твою идею, спасибо! Но возможно есть варианты покрасивее с коробки?) По аналогии с тем как сделаны очереди

У меня была мысль запустить эту задачу в планировщике задач, и что бы он убивал её по таймауту и начинал по новой, но тоже какой-то костыль получается

так очереди бегают в бесконечном цикле и проверяют не было ли вызова на перезагрузку, в твоем случае почти тоже самое, да и subscribe скорее всего также реализован, только реализация скрыта от пользователя, а вот если заглянуть в исходник там скорее всего тоже будет цикл.

Да ты прав, пока не вижу лучшего варианта чем слушать доп событие "restart" при получении которого завершать команду

или по аналогии с isDownForMaintenance(), которая смотрит если файл есть значит сайт на облуживании, в твоем случае можно создавать файл и если он есть то умирать, перед этим удалив файл.

Да тоже как вариант, но опять же для этого нужно попасть в цикл который выполняет Redis::subscribe, а такой возможности нет, разве что в supervisor'е прописать команду что бы она смотрела на файл

Спасибо всем за советы. Ввиду "нюансов" пресловутого SQL2000 и необходимости ещё и возможностей фильтрации-сортировки... На уровне класса (laravel) нормальный pagination написать по сути невозможно ввиду того как вообще реально организовать постраничные выборки в SQL2000. В итоге решение:
1.  Хранимка в SQL, которая формирует страничную выборку по таблице с возможностью фильтрации и сортировок.
2. Простая "метод-обёртка" в базовом контроллере, которая обрабатывает кодировки и формирует вызов хранимки.

В итоге в контроллере только вызов метода getWithPaginate с разбором $request (page/pageSize).

Кстати, pagination через хранимку работает весьма резво - на таблице около 4млн. записей с фильтрацией через LIKE по 3 индексированным полям произвольную страницу формирует в пределах 0,2сек. Без фильтрации - не больше 0,05 сек. Всем спасибо.

Спасибо большое.

Теперь при помощи карбона вывожу именно так, как надо.

Теперь только вопрос, а как быть при  сохранении?

Сеейчас при попытке сохранить в БД пытается сохранится datetime дата.

Как сделать так, чтобы в БД писался unixtime() ?

А зачем, если каст для даты указан, он сам его в карбон оборачивает, ты можешь уже потом применить просто format()

Привет )
Подскажите, есть ли возможность получить результат запроса (через Builder) как массив, а не stdObject ?

Речь идёт о laravel 8
Я смотрю, что FETCH_MODE захардкожен и его изменить нельзя

а чем не устраивает toArray?

туплю, соре