Serhiy Romanov

Джанго хранит такие объекты в UTC, а временную зону применяет в момент рендера в темплейт. Т.е. вам надо руками это обработать.

from django.utils import timezone
tz = timezone.get_default_timezone()

class A(models.Model):
    created = models.DateTimeField()
    def __str__(self):
        return 'Заявка от {}'.format(self.created.astimezone(tz).strftime('%d.%m.%Y %H:%M'))

запросы к API надо делать внутри actions Vuex (якобы это best practices). Однако, я совершенно не понимаю, всегда ли это необходимо

state нужен в тех случаях, когда доступ к списку пользователей вам нужен не в одном компоненте, а как минимум в двух. В таких случаях без него никак.

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

Важно понимать разницу:

• Данные в Vuex "существуют" всегда и всегда занимают часть памяти на клиенте.
  
• Данные в компоненте "существуют" только когда существует компонент. И будут удалены если удалится компонент.
  

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

В то же время, если список пользователей вам нужен только для какого-то виджета, который отображается не всегда — тогда хранить данные в Vuex не стоит.

См. также

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

Это вопрос уже совершенно другого направления.

Создать и вызвать мутацию addUser для добавления нового пользователя в state?

Да. Actions для того и существует, чтобы вы могли выполнить какие-то асинхронные запросы, доп проверки, валидацию данных, определить нужно ли что-то сохранить в state и если нужно — что именно. Здесь вы можете добавить пользователя, проверить добавился ли он, выполнить дополнительный запрос на извлечение информации о нем. И тп.
А мутация — непосредственно алгоритм изменения состояния.

в чем тогда смысл нашего state?

Локальная, быстрая, реактивная копия данных с сервера на клиенте.

при любом действии все равно необходимо загружать данные с сервера

Это уже вопрос к серверу. И к его API. Есть много разных технологий синхронизации данных между сервером и клиентом.

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

Используйте lxml без прокладки в виде bs

Для начала - записать запрос понагляднее. В условиях ON записать поля присоединяемой таблицы в левых частях сравнений:

SELECT * 
  FROM `tbl_1` 
  LEFT JOIN `tbl_2` ON `tbl_2`.`id_fp` = `tbl_1`.`foto_id` AND `tbl_2`.`sklad` = 'Склад' 
  WHERE (deleted="no" AND `where`="arh")  AND (`type`="Cloth" ) 
  ORDER BY `foto_id` ASC 
  LIMIT 9447,20;

Теперь видно, что для ускорения JOIN'а стоит сделать в таблице `tbl_2` составной индекс (`id_fp`, `sklad`).
Затем надо смотреть EXPLAIN и, возможно, переносить условия из WHERE в предварительную выборку из `tbl_1`.
Но, если к одной строке из `tbl_1` присоединяется несколько строки из `tbl_2`, то ORDER BY и LIMIT надо оставить снаружи.

SELECT * 
  FROM (
    SELECT *
      FROM `tbl_1` 
      WHERE (deleted="no" AND `where`="arh")  AND (`type`="Cloth" ) 
      ORDER BY `foto_id` ASC 
      LIMIT 9447,20
  ) AS `t1`
  LEFT JOIN `tbl_2` ON `tbl_2`.`id_fp` = `t1`.`foto_id` AND `tbl_2`.`sklad` = 'Склад'

Ну и, напоследок, заменить * на необходимый список полей, чтобы не тянуть из базы лишние данные.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

1. Уникальность лучше ставить на уровне БД. Переопределить юзера, в Meta-классе дописать unique_together = [['email']]
2. Если первый пункт по каким-то причинам отметается, метод unique_email замени на clean_email и FormView будет сам вызывать его. К тому же, эксепшены из unique_email ты никак не отлавливаешь, вот он и вываливает ошибку.
3. if User.objects.filter(email=email).count() > 0 and email: - это неэффективно. В первую очередь, нужно проверять на то, что email не пуст, а потом уже на то, что он присутствует в БД (меньше запросов). К тому же, count вызывать для этого затратно. Лучше сделать так:

if email and User.objects.filter(email=email).exists():

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

Проще всего пойти стандартным путем: унаследовать пользователя от django.contrib.auth.models.AbstractUser, а различие между пользователями определять либо по группе/разрешениям, либо добавить поле в свою модель типа is_moderator. Это будет во много раз (на порядок точно) проще реализовать и поддерживать, будет совместимость со всем стандартным кодом Django и сторонними библиотеками, любому просто войти в проект и внести изменения.

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

TLDR:
1) Из вашего вопроса остается неясным, почему требуется разделение по разным классам. Это самый безумный вариант для разграничения полномочий, и в Django разделение полномочий пользователей уже предусмотрено по умолчанию
2) Поддерживал пару проектов с разными классами для разных классов пользователей. Поверьте, это просто ужас-ужас в поддержке, а самое главное, что он ничем не оправдан.