Привет, можно ли поставить выполнение очереди через месяц/2 месяца/год и

тд... И нормально ли это?

Отложенные задачи вроде есть. Но использование их для таких больших delay - действительно сомнительно. Опиши плиз задачу, которая приводит к этому решению

Кажется для подписки?

Аренда приложения

Got it. Может быть поможет поле типа expired_at, метод isExpired() у модеди, и завязка этого метода в бизнес логику?

Легче указать дату окончания, потом сделать планировщика который деактивирует подписку/аренду

Тут можно даже без асинхронности обойтись

Но тогда надо обращаться не менее раза в минуту или есть идеи ?

У тебя на окончание подписки большая логика указана?

Да, но как вариант

можна в самой подписке сделать дату expired_at и поставить фильтр что если expired_at меньше чем сейчас то подписка неактивная

Нет, мизерная

Ок, спасибо )

Честно не догнал, можно конкретней, я не вижу беды отправлять каждую минуту или секунду запрос через планировщик

Т.е логика такая что когда пользователь заходит данные синхронизируются?

Можно даже без него. У модельки по методу isExpired() всегда явно указывается состояние подписки. А проверять его можно явно где угодно. Например в Policies перед тем, как пользователь захочет сделать что-то, на что подписан

Нет, мне кажется это слишком ибо сервер полу дохлый, запросов много, посетителей тоже много...

Нет. Один раз ставим дату окончания подписки, потом читаем и сравниваем. Что-то типа $subscription->expired_at > now

Ну вот т.е пока пользователь активен мы можем контролировать его подписку

Но ведь ты будешь дёргать экземпляр подписки в любом случае? Или нет?

В том то и прикол

Ааа, понял. Просто если бизнес-логики мало, то и технические решение лучше будут маленькими (моё мнение)

У меня есть таблица типо id|user_id|product_id|дата начала|дата конца И мне надо тупо если дата сейчас больше чем дата конца, то меняем например дату или статус и отправляем месседж юзеру, либо чекрез jobs по дате конца

Тут просто есть нюанс, что дата может поменяться

В чем проблема, запускаем глобальный планировщик, делаем запрос к был проверяем дату окончания, поменялось или нет не имеет значение, по окончанию или до окончания отправляем юзерам уведомление

ООО, так это то, что я описал. Просто через планировщик

Угу

Так, а можно сделать просто запрос ->where('Дата окончания' , '<=', 'Текущая дата' )->get(); А потом удалять их или менять статус Но все же каждый раз делать такой запрос кажется грамоздко, хотя не придется парится с очередями

Всё ты правильно сказал. Но - делай это через chunk(10). А ещё круче внутри замыкания чанка бросай задачу в очередь - ведь там же высылаются мэйлы. Одна задача на каждую плдписку = одна задача на каждый мейл.

Вы делаете такой запрос раз в минуту или раз в час, это не будет влиять на нагрузку

Solidность

Тут не про SOLID. Просто chunk предотратит проблемы с тем, что миллион запись сразу полезут в оперативку, а на проде не всем выделяют кучу памяти для обычных планировщиков. А пробрасывание каждого экземпляра через очередь позволит распределить нагрузку - снять основную нагрузку из команды планировщика, и положить её на очередь