Как реализовать очередь сообщений?

Question

[fokioff]

При написании бота столкнулся с проблемой: не могу придумать как реализовать очередь сообщений. Кратко, администратору после регистрации анкеты присылается эта самая анкета и кнопки к ней "одобрить", "отклонить". В базу данных, в отдельную строчку, записывается userid пользователя, который зарегистрировался:

cur.execute(
                f'''UPDATE users SET userid = {message.from_user.id} WHERE username = "admin"'''
)

cur.execute(
                f'''SELECT userid FROM users WHERE username = "admin"''')
userid = cur.fetchone()[0]

При нажатии одобрить из базы данных достаётся userid и бот отправляет по нему сообщение:

await bot.send_message(userid, "Ваша анкета одобрена!")

Однако, если зарегистрируется к примеру 1 человек, его userid отправится в базу, (предположим, что администратор не обработал его) а затем зарегистрируется второй человек, и соответственно его userid тоже отправится в базу, в которой заменит прошлый userid.

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

Как это можно решить? Буду очень благодарен!

Comments

[Александр]

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

Answer 1

[Алан Гибизов]

Храните в БД все заявки вообще, сразу заносите их. Просто добавьте булево поле «рассмотрено» и булево поле «одобрено» (по-умолчанию оба поля false). Когда админ добирается до рассмотрения заявок, он получает заявки, где «рассмотрено» == false, и после рассмотрения оно становится true, а «одобрено» либо останется false, либо станет true.

Comments

[Everything_is_not_so_bad]

лучше enum поле `state`, чем просто булевское значение.

[Slava Rozhnev]

Еще логичней ограничится одним полем. Не рассмотрено - NULL, рассмотрено - значение

[Алан Гибизов]

Роман Мирр, какие значения должно принимать поле enum?

[Алан Гибизов]

Slava Rozhnev, можно, но есть нюанс:
Явно лучше, чем неявно. Поэтому я бы предпочёл явные два поля, с которыми понятно что делать, одному полю с не всем понятным поведением.

[Everything_is_not_so_bad]

Алан Гибизов,
числовыми значениями типа одобрено/отклонено и т.д. Тогда любые добавки новых статусов не приведут к необходимости изменения поля таблицы.