Сергей Горностаев

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

Зачем такие сложности? Достаточно добавить в каждую модель поле tenant и при выборке записей фильтровать по значению этого поля.

Сделать базовый абстрактный класс и наследовать от него. Соответствующий раздел документации.

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

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

Для таких задач нужен видеостриминг, а Django для этого фреймворк неподходящий.

1. Прочитать документацию Django;
   
2. Понять, что такое {% static %}, что он делает и зачем это нужно;
   
3. PROFIT!
   

Ещё можно заглянуть в консоль браузера, посмотреть какие ошибки там отображаются и при обращении по каким адресам они возникли.

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

На VPS'ах web-сервер настраивается на раздачу статики, а на shared хостингах всегда есть инструкция куда положить статику, чтобы их web-сервер мог её раздавать.

Для этого можно inclusion tag написать или рендер. Всë это описано в документации.

Конечно, он описан в документации.

DRF - это просто модуль добавляющий в Django батарейки для упрощения реализации REST API. Так что ваш вопрос звучит как "Надо ли мне учиться водить автомобиль, если я установлю в него подогрев сидений?"

Во-первых, такие поля вообще не стоит иметь. Во-вторых, если уж они есть зачем-то, то их стоит менять в обработчиках сигналов, а не в методе save. В-третьих, если нужно пересчёт в режиме реального времени, то это задача фронта, то есть надо написать соответствующий javascript-код и внедрить его в админку.

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

https://docs.djangoproject.com/en/4.2/topics/forms...

Во-первых, {% url 'lang:about' %} Во-вторых, url'ы должны следовать от более конкретных к менее конкретным.

Это называется formset и подробно описано в документации.

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