sudo -u postgres psql
drop user rudius;
create user rudius login password 'passwordtest';
create database testdb with owner rudius;

И в настройках:
'NAME': 'testdb'

всем привет, а в чем заключается особенность хранения всех моделей в одном файле, ведь нарушается принцип single responsibility?

Так лучше не делать

Доброго дня. Подключен allauth,  аутентификация по имейлу, стоит обязательная верификация. Засаживаю бд (seeds), пытаюсь создавать юзера, что бы не надо было подтверждать аккаунт, но никак не выходит. Кто-то сталкивался с этим ? is_active=True не проходит.

Там когда  подключаешь allauth, у тебя создается таблица account_emailaddress (у меня так)
там есть колонка с verified. Скорей всего тебе нужно устанавливать verified = True, либо =1

не с primary, а с verified*

Получается тебе надо отключить верификацию по емайлу?

Именно когда засаживаю бд юзером

verified = True/1 тоже не отрабатывает

Вообще я хотел сделать фронт на питоне. Фрейворк типа vue, код генерируетсяя через transcrypt или подобное. Оно само будет смотреть какие данные есть на клиенте, за какими надо лезть в базу - их оно будет по типу rpc на бэке делать.

как те идея. т.е. я условно говоря пишу не rest запросы а просто код который с орм работает. или нет. и оно само решает где ему выполняться

а ещё я хочу сделать серверный рендер vue без ноды. едиственная проблема это если js expressions прямо в шаблонах т.е. всякие <foo v-if="Object.own_property(eval(Owl.owl))">

from django.conf.urls import url
from . import views

urlpatterns = [
   # post views
   url(r'^$', views.post_list, name='post_list'),
   url(r'^(?P<year>\d{4})/(?P<month>\d{2})/(?P<day>\d{2})/'\
       r'(?P<post>[-\w]+)/$',
       views.post_detail,
       name='post_detail'),
] - как это написать на django 3?

Т.е. можно писать шаблон по типу того что на vue, react и т.п.
Там может быть код типа
class Computed:
   def users(self):
       return User.objects.all()
   def paginated(self, page=0):
       return self.data[page*20;20]
paginated будет скомпилирован в js и выполнится на клиенте. И если код - чистая функция и т.п.
если там делгается orm оно само создаст endpoint и будет делать запросы прозрачно. т.е. этот код будет выполняться на бэке, а на фронте скомпилируется обвязка чтобы его вызывать.

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

Почему

Часто моделей становится больше и файл раздувается, вместо этого можно сделать models пакетом, внутри создать отдельный файл для каждой модели и импортировать написанные модели в init.pyinit.py в переменную all

Если взё разбито по app`ам, в одном приложении не так много моделей. В моделях не должно быть жирной логики. Так что одного файла обычно достаточно. Не вижу смысла создавать по файлу на класс, привет circular imports и прыганье по файлам.
Лучше в отдельный файлы убирать managers, querysets, helpers/utils, сигналы и т.п.

apps.get_model в случае чего решат проблемы импортов, managers/querysets - тоже в отдельные файлы, но кучи apps не практикуем - в одном сервисе максимум 5, иначе домен слишком быстро расплывается

Вообще это конечно вкусовщина. Просто насмотрелся тут. На разное. Файлы с тысячами строк. Или когда вичи джанго вообще не используются везде просто APIView с лапшой года. Или  function-based views тоже которые ещё надо затылок почесать как разбить.

К моделям в разный файлах отношения не имеет. Просто представил себе что там 100 моделей в app)