Как сделать достижения в асинхронном боте телеграм(aiogram)?

Question

[black_dis]

Я пишу бота на aiogram с бд sqlite3. С асинхронкой пересекаюсь впервые. К примеру я имею:

@tg.message_handler(commands = ['start'])
async def send_welcome(msg: types.Message):
....
@tg.message_handler(content_types = ['text'])
async def sender(msg: types.Message):
....
@tg.callback_query_handler(lambda call: True)
async def callback_inline(call):
....
И вот как мне написать новую функцию, которая вечно проверяет данные юзера с бд, чтобы в случае достижения нужного результата она отправляла сообщение об выполненном достижении?

Comments

[Рамис]

С асинхронкой пересекаюсь впервые.

И поэтому, вы сразу начали писать асинхронного бота

[black_dis]

Рамис, Спасибо, за раскрытый ответ на поставленный вопрос.
Взялся за aiogram из-за множества советов сразу браться за него, дабы после не переучиваться/переписывать код под него.

[Рамис]

black_dis, Ответы оставляют немного ниже, я же оставил комментарий.
Мой совет, забыть на время про aiogram, изучить, понять как работает асинхронный код.

дабы после не переучиваться/переписывать код

Если бот станет популярным, переписать все равно придется (Webhook передает привет)

Answer 1

[Vindicar]

Грубо говоря, для асинхронной программы верно одно утверждение: "пока ты выполняешь код, не являющийся await вызовом, остальная программа простаивает".
Каждый await вызов (а также его завершение) - это повод переключиться на другую задачу.
Таким образом, бесконечный цикл - это просто:

while True:
  await asyncio.sleep(5) #пока текущая корутина спит, остальной бот работает
  do_stuff() #пока do_stuff() работает, остальной бот спит

Вопрос в другом: нужен ли бесконечный цикл?
Я бы посоветовал начать с создания системы сбора статистики.
Например, завести таблицу вида id юзера - имя статы - значение статы.
Скажем "id - число_сообщений - 100500". И в обработчиках соответствующих событий делать UPDATE на эту таблицу. А потом в отдельном модуле периодически проверять статы пользователей, проверять, есть ли у них уже ачивка за эту стату, и если нет - то давать.

Comments

[black_dis]

Благодарю за ответ.
Смотрите, приведенный сбор статистики имеется. Допустим я имею money, который при определенных условиях пополняется и мне нужно как вы сказали сделать отдельный модуль для проверки. Вот тут у меня, собственно, и заминка. Единственным решением отдельной проверки я вижу как отдельное условие в прослушке сообщений, но тогда информация об полученном достижении поступит только после того, как кто-то напишет соо и не всегда это будет моментально

[Vindicar]

black_dis, Как вариант, можно оформить проверку на достижение сразу после изменения статы, ответственной за это достижение. Например, таким образом.

stat_checks = {
  #проверяемая стата
  'messages_sent': [
    #функция или лямбда для проверки ачивки, id ачивки
    ( (lambda v: v > 100), 'achievement_100_messages'),
  ],
  'voicechat_time': [
    #...
  ],
}

Тогда у вас будет функция для повышения статы типа

def stat_bump(user_id, stat_id, delta):
  #выполняем запрос UPDATE/INSERT для статы stat_id
  query(...)
  #узнаем текущее значение статы stat_id
  stat_value = ...
  #узнаем ачивки пользователя
  achievements  = ...
  for predicate, achiev in stat_checks.get(stat_id, []):
    if predicate(stat_value) and (achiev not in achievements):
      #набрал стату на ачивку, но ачивки такой ещё нет!
      give_achievement(achiev, user_id)

[black_dis]

Vindicar, я ничего не понял, но за старание донесения - лайк и отметка решения)

[Vindicar]

black_dis, ну пример. Мы хотим давать ачивку, когда пользователь наберёт 100 сообщений на сервере.
Тогда при реакции на сообщение мы должны изменить соответствующую стату - сделать stat_bump() с указанием id пользователя, статистики, которая нас затронула (в нашем случае я её назвал messages_sent) и насколько мы эту стату увеличиваем (в нашем случае на 1).
И вот этот момент и является оптимальным для проверки на получение новых ачивок, как раз когда стата изменилась. Мы можем хранить (в stat_checks) для каждой интересующей нас статы ряд проверок, и ачивок которые они дают, и прогнать эти проверки чтобы понять, какие ачивки будут у пользователя.
Единственное, нужно учесть, какие ачивки уже есть, иначе за каждое сообщение после 100 пользователь будет снова и снова получать ачивку X)

[black_dis]

Vindicar, тогда я вас понял. Единственное, я думал насчет этого, но решил избежать подобного способа, ибо это бесконечный ряд проверок на количество сообщений и получена ли уже ачивка. Не знаю, оптимально ли это. Именно поэтому и думал, вдруг возможно сделать асинхронно отдельную функцию которая может это проверять вне основного кода

[Vindicar]

black_dis, возможно, но тогда эта функция будет непрерывно перелопачивать базу и проверять все возможные ачивки для всех пользователей поочерёдно. В том числе те, которые зависят от стат, меняющихся раз в год. В том числе для пользователей, которые уже сто лет не появлялись.
Мне кажется, это намного хуже. В принципе, тебе никто не мешает реализовать вышеописанную проверку как асинхронный таск, запускающийся параллельно обработчику события, особенно если запросы к БД тоже будут асинхронными. Она же не будет связана с логикой основного обработчика...