H
Легче указать дату окончания, потом сделать планировщика который деактивирует подписку/аренду
Но тогда надо обращаться не менее раза в минуту или есть идеи ?
Size: a a a
2021 March 22
IM
HahahImFaus
Но тогда надо обращаться не менее раза в минуту или есть идеи ?
У тебя на окончание подписки большая логика указана?
S
Тут можно даже без асинхронности обойтись
Да, но как вариант
H
У тебя на окончание подписки большая логика указана?
Нет, мизерная
AK
HahahImFaus
Но тогда надо обращаться не менее раза в минуту или есть идеи ?
можна в самой подписке сделать дату expired_at и поставить фильтр что если expired_at меньше чем сейчас то подписка неактивная
IM
можна в самой подписке сделать дату expired_at и поставить фильтр что если expired_at меньше чем сейчас то подписка неактивная
Вот в эту сторону я и рекомендую копать :)
К
Чел просто копирнул не то, жидко обосрался, от него воняет говном, он чувствует, что воняет.
Но говорит: нет, это не я обосрался, это вы все обосрались
Но говорит: нет, это не я обосрался, это вы все обосрались
у тебя же доказательств нет, одни домыслы, поэтому вопрос открыт кто еще обосрался. Если бы была проблема в этом я сразу бы так и написал, зачем мне говорить обратное? Первым же сообщением поблагодарил за помощь, а тут видимо не благодарить а проклянать нужно таких "помощников".
ЕК
S
Ну хватит уже
H
Вот в эту сторону я и рекомендую копать :)
Ок, спасибо )
IM
HahahImFaus
Нет, мизерная
Тогда можно не использовать асинхронные решения, а всё привязать на синхронное явное
$subscribtion->isExpired()AK
у тебя же доказательств нет, одни домыслы, поэтому вопрос открыт кто еще обосрался. Если бы была проблема в этом я сразу бы так и написал, зачем мне говорить обратное? Первым же сообщением поблагодарил за помощь, а тут видимо не благодарить а проклянать нужно таких "помощников".
я сейчас подниму докер и посмотрим)
S
Вот в эту сторону я и рекомендую копать :)
Честно не догнал, можно конкретней, я не вижу беды отправлять каждую минуту или секунду запрос через планировщик
S
Тогда можно не использовать асинхронные решения, а всё привязать на синхронное явное
$subscribtion->isExpired()Т.е логика такая что когда пользователь заходит данные синхронизируются?
К
я сейчас подниму докер и посмотрим)
а без докера слабо? я делал без докера, с докером любой дурак может, даже дока не нужна
IM
Честно не догнал, можно конкретней, я не вижу беды отправлять каждую минуту или секунду запрос через планировщик
Можно даже без него. У модельки по методу isExpired() всегда явно указывается состояние подписки. А проверять его можно явно где угодно. Например в Policies перед тем, как пользователь захочет сделать что-то, на что подписан
H
Честно не догнал, можно конкретней, я не вижу беды отправлять каждую минуту или секунду запрос через планировщик
Нет, мне кажется это слишком ибо сервер полу дохлый, запросов много, посетителей тоже много...
AK
а без докера слабо? я делал без докера, с докером любой дурак может, даже дока не нужна
а какая разница с докером или без?
чисто локальный комп не засорять
чисто локальный комп не засорять
IM
Т.е логика такая что когда пользователь заходит данные синхронизируются?
Нет. Один раз ставим дату окончания подписки, потом читаем и сравниваем. Что-то типа $subscription->expired_at > now
S
Можно даже без него. У модельки по методу isExpired() всегда явно указывается состояние подписки. А проверять его можно явно где угодно. Например в Policies перед тем, как пользователь захочет сделать что-то, на что подписан
Ну вот т.е пока пользователь активен мы можем контролировать его подписку