Roman K

Используй black и не задавай таких вопросов

https://docs.djangoproject.com/en/4.0/ref/contrib/...

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

Ты добавил поле, поле это не может быть NULL. Но в базе уже могут находиться записи, которые, очевидно, не содержали этого поля (потому что ты его только что добавил). А значит, всем существующим записям нужно что-то поставить в это поле.

Хотя достаточно было перевести текст, там ведь тоже самое написано.

Читаем внимательно и вдумчиво https://docs.djangoproject.com/en/4.0/topics/http/urls/

Что значит "как"? Ответь на вопрос: как получить все файлы, связанные с моделью? Вот теперь оформи это в метод модели

def get_all_my_files(self) -> list[str]:
    result = []
    result.extend(get_from_here())
    result.extend(and_from_there())
    return result

И повесь на pre_delete сигнал получение файлов, а потом удаление

Первое. daphne — на помойку. Я в своё время наплевался с неё и переехал на gunicorn + uvicorn. Потому что daphne вообще не настраивается. Вот сколько у вас процессов-воркеров, по-вашему? А сколько потоков? А сколько ивент-лупов? А зачем ему сертификаты? Стало быть, это сервер, который может торчать наружу? Но ведь это не так.

Второе — в зависимости от типа задачи, которая выполняется "3-10 секунд", нужно или забить на это, или выносить в очередь. Если это IO, то асинхронная функция может длиться хоть вечность, она не будет влиять на соседние запросы (на самом деле конечно будет, но крайне незначительно). Если это CPU — только очереди задач. Celery например. Но с ним тоже много проблем, поэтому мы последнее время пишем самописные django-management команды, которые слушают очередь.

Третье. Джанга в целом не очень хорошо подходит для асинхронщины по дизайну (и вебсокетов соответсвенно тоже). Да, есть неуклюжие попытки в виде channels и даже django 3 по подружению её с миром асинка, но это всегда большие компромиссы с большим количеством "но". Поэтому, если есть возможность (например, проект стартовал "вчера"), то переезжай на что-то более способное в настоящую асинхронность (fastapi например)

Есть ровно ноль причин использовать Flask в 2021 году для новых проектов.

В отличии от джанги у flask нет кучи полезных фич, которыми можно накостылять и быстро стартануть
В отличии от fastapi, у flask нет типизации, DI и честной асинхронщины (она такая же, как у джанги — per view)
У фласки есть фундаментальная дичь вроде global scope request

Зависит того, как они написаны и какой трафик. Но скорее нет, чем да, 512мб мало для трёх джанг

Нет группировки по number, потому что есть группировка по number, type.

В DRF логику не делают и через DRF логику не делают. DRF — это слой контроллеров и слой отображения. Он делает за тебя грязную работу в виде ACL, маппинга сущностей туда-обратно между ORM и JSON, фильтры там всякие. Логику ты пишешь в сервисах или моделях

Но DRF использовать скорее стоит, особенно в начале разработки

https://docs.djangoproject.com/en/3.2/topics/db/qu...

Всегда удивляли и удивляют доводы против джанги на тему "ну это же комбайн". Да, комбайн, и чё? Что значит "не слишком ли массивен"? Не вместится на впску? Да вроде вместится, не переживай. По этой логике, массивен тут скорее питон, потому что интерпретатор с зависимостями весит 100+мб. Или логика "массивен = лагает"? А у твоего лендинга будет нагрузка в две тысячи запросов в секунду и больше, чтобы переживать?

Функциональность фреймворка должна быть надмножеством требуемой тебе функциональности. И чем больше функциональности сверх твоих требований, тем больше места для манёвра ты себе оставляешь. Остальные доводы неуместны.

Посчитать, сколько пользователей имеют рейтинг больше, чем у искомого