AB
Берём owner|dog. От него получаем все его dog_owner записи 1:N. От них получаем walks 1:1
а как мы получим walks, если эта таблица не содержит никаких ссылок на dog_owner?
Size: a a a
2021 March 07
SC
А, то я проебланил. Да, dog_owner_id это как раз нужная ссылка
SC
Ну значит нужна, да
AB
Соответственно вот тебе связь owner->walks
мы сейчас не на одной волне и просто не понимаем друг друга
AB
А, то я проебланил. Да, dog_owner_id это как раз нужная ссылка
аа, я уж испугался
OS
Дак ты же из джобы вызываешь API чужого сайта. Как чужому сайту узнать запускал ли ты вызов через джобу?
внешнему сайту не обязательно этого знать.
1. У меня есть какой то метод, всеравно что он делает.
2. Как мне получить, то что это метод был вызван в очереди внутри метода?
Забываем про апи.
1. У меня есть какой то метод, всеравно что он делает.
2. Как мне получить, то что это метод был вызван в очереди внутри метода?
Забываем про апи.
AB
или может нахрен эту смежну таблицу? воткнем все в
walks?блин эта смежная таблица все портит 🧐🤨
AH
внешнему сайту не обязательно этого знать.
1. У меня есть какой то метод, всеравно что он делает.
2. Как мне получить, то что это метод был вызван в очереди внутри метода?
Забываем про апи.
1. У меня есть какой то метод, всеравно что он делает.
2. Как мне получить, то что это метод был вызван в очереди внутри метода?
Забываем про апи.
OS
есть фасад которые вызывается в методе handle задачи очереди. Как внутри фасада определить, что он был вызван из очереди?
OS
🎃
есть фасад которые вызывается в методе handle задачи очереди. Как внутри фасада определить, что он был вызван из очереди?
чекнуть app->runningInConsole(), и можно глянуть аргументы запуска процесса, или по debug_backtrace() глянуть есть ли запуск из очереди
OS
чекнуть app->runningInConsole(), и можно глянуть аргументы запуска процесса, или по debug_backtrace() глянуть есть ли запуск из очереди
вот это звучит как план, окей, а как теперь отделить Artisan Command от очереди?
🎃
вот это звучит как план, окей, а как теперь отделить Artisan Command от очереди?
а что не так?
SC
есть фасад которые вызывается в методе handle задачи очереди. Как внутри фасада определить, что он был вызван из очереди?
У тебя постановка задачи отвратительная) Если есть API с лимитом обращений, значит следовало бы написать какую-то логику по управлению задачами в зависимости от этих лимитов. Мы типа хранили похожую историю в привязке к пользователю и уже зная когда лимиты истекают или при достаточном количестве «кредитов» запускали задачи.
OS
У тебя постановка задачи отвратительная) Если есть API с лимитом обращений, значит следовало бы написать какую-то логику по управлению задачами в зависимости от этих лимитов. Мы типа хранили похожую историю в привязке к пользователю и уже зная когда лимиты истекают или при достаточном количестве «кредитов» запускали задачи.
а каким образом в 1 очереди разделяли лимиты для каждого пользователя?
🎃
надо не давать добавлять очереди если лимит вышел
SC
а каким образом в 1 очереди разделяли лимиты для каждого пользователя?
В смысле в 1 очереди?
Есть задача, сделать какую-то операцию для пользователя, которая требует дёрнуть API. API аутентифицируется через oauth токен пользователя, т.е. лимиты идут per user, а не на всё твоё приложение.
Ну и соответственно, запустил там по крону задачу которая колупашит юзеров, чекает их лимиты и ставит или не ставит задачу
Есть задача, сделать какую-то операцию для пользователя, которая требует дёрнуть API. API аутентифицируется через oauth токен пользователя, т.е. лимиты идут per user, а не на всё твоё приложение.
Ну и соответственно, запустил там по крону задачу которая колупашит юзеров, чекает их лимиты и ставит или не ставит задачу
SC
В контексте приложения тоже самое, только хранишь остаток «кредитов» глобально
SC
Хорошо работает, если количество запросов к API плюс-минус детерминировано
OS
В смысле в 1 очереди?
Есть задача, сделать какую-то операцию для пользователя, которая требует дёрнуть API. API аутентифицируется через oauth токен пользователя, т.е. лимиты идут per user, а не на всё твоё приложение.
Ну и соответственно, запустил там по крону задачу которая колупашит юзеров, чекает их лимиты и ставит или не ставит задачу
Есть задача, сделать какую-то операцию для пользователя, которая требует дёрнуть API. API аутентифицируется через oauth токен пользователя, т.е. лимиты идут per user, а не на всё твоё приложение.
Ну и соответственно, запустил там по крону задачу которая колупашит юзеров, чекает их лимиты и ставит или не ставит задачу
у меня запросы приходят от пользователей, мы не можем их не обработать. Поэтому они ложатся все очередь.
У очереди есть 100 воркеров, которые разбирают эти задачи и стараются выполнить. Лимиты сохраняются глобально в редисе, на случай если кто-то захочет сделать запрос из контроллера еще.
Но как только параллельные потоки привышают литим запросов внешнего API, оно кидает header retryAfter и мы можем сделать release задачу на это время. А в это время у нас могут выполнится задачи для других API например, или других пользователей
У очереди есть 100 воркеров, которые разбирают эти задачи и стараются выполнить. Лимиты сохраняются глобально в редисе, на случай если кто-то захочет сделать запрос из контроллера еще.
Но как только параллельные потоки привышают литим запросов внешнего API, оно кидает header retryAfter и мы можем сделать release задачу на это время. А в это время у нас могут выполнится задачи для других API например, или других пользователей