Каким образом реализовать иерархию пользователей?

Question

[Mikkkch]

Здравствуйте, я работаю над старым пет-проектом, основным функционалом которого является публикация объявлений. В первую очередь хотелось бы отметить, что этот вопрос является неким дополнением к заданному мною ранее.

Суть заключается в следующем:
Недавно зарегистрированный пользователь имеет доступ к созданию только трех объектов в день.
Соответственно, если человек хочет обзавестись большим численным показателем, ему необходимо чего-то достичь.
Так-как четкой реализации я пока-что не вижу, то возьмем количество просмотров на его объектах в качестве показателя достигнутого.
Когда у пользователя будет образно тысяча просмотров на публикации, мы его наградим статусом выше текущего и завысим планку до следующего статуса.
Нужно, чтобы связь между статусом, тем, что позволяет статус и то, каким образом он достигается наблюдалась.

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

Интересует сама реализация(возможно миксин какой-то написать, в котором вся перечисленная логика будет наблюдаться). И интересует сам процесс фиксации того, что пользователь достиг какой-то планки.

Answer 1

[Владимир]

Я бы танцевал от того, в какой момент меняется показатель, к которому привязан статус. Скажем, если это просмотры объявления, то в какой момент фиксируется +1 просмотр. В этом куске кода подняли просмотры на один, дернули из базы юзера-владельца и вызвали у него соответствующий метод, скажем check_and_update_status(), передав ссылку на объявление. И уже в этом методе отрабатываем проверку на повышение статуса.

Или для гибкости сделать функцию-диспетчер, подписать ее на кастомный сигнал view_count_increased, после увеличения числа просмотров посылать этот сигнал, а уже в диспетчере обращаться к юзеру. Это будет менее наглядно (и в документации так не советуют делать), зато более гибко, можно будет в любой момент отключить или изменить эту часть логики.

Это только то, что сходу пришло в голову, наверняка более опытные коллеги смогут подсказать лучше.

Comments

[Mikkkch]

пока что в Вашем предложении я вижу решение. А ничего противоестественного не будет, если этот метод check_and_update_status() будет таской? Есть ли в этом вообще смысл? Чтобы пользователь, зашедший на страницу какого-то объекта не сидел и не ждал, когда мы убедимся в том, что автору нет смысла повышать статус или наоборот. Тут уже момент с тем, что вряд-ли объект пользователя благополучно попадет в аргументы таски, так что буду отталкиваться от Вашего ответа.

[Владимир]

Скажу честно: с асинхронным кодом я очень поверхностно знаком. В идеале да, нужно так или иначе выводить такие запросы из основного потока, но детально не подскажу.

[Mikkkch]

Владимир, спасибо большое за помощь. Комментарий под ответом Dr.Bacon’а прочел.