Создать или изменить таблицу PostgreSQL, чтобы обеспечить соответствие моделей Django - PullRequest
Новая
       22

Создать или изменить таблицу PostgreSQL, чтобы обеспечить соответствие моделей Django

0 голосов
/ 16 ноября 2018

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

Давайте назовем мою «тестовую» БД: testDB и мою «dev» БД: devDB

Я обращался к testDB как обычно через Django settings.py, и я произвел миграцию, добавив поле clientID , которое вы видите в приведенном ниже коде.

Затем я решил переключиться на devDB вмой файл Django settings.py для запуска python manage.py migrate , и мое поле clientID не добавляется в новую БД.Когда я запускаю python manage.py makemigrations я получаю, как и ожидалось, "не обнаружено никаких изменений".

Как раз для того, чтобы это отметить, я использую пакет django-reset-migrations из PyPiпосле того, как я выполню миграцию, чтобы папка миграций не усложнялась и все сохранялось в одном файле миграций 0001_initial.py.

Я не вижу лучшего способа решения этой проблемы, чем написание собственного сценария, который обеспечиваетвсе таблицы моделей существуют в любой БД, к которой я подключен, и что все поля модели находятся в каждой таблице, в противном случае таблица изменяется и добавляются соответствующие столбцы, что приводит меня к моему вопросу ...

Если я использую: python manage.py sqlmigrate объектов 0001 (это мой файл 0001_initial.py), мне предоставляется код создания ниже: 

CREATE TABLE "objects_users" (
    "id" serial NOT NULL PRIMARY KEY, 
    "clientID" integer NOT NULL, 
    "email" varchar(100) NOT NULL, 
    "first_name" varchar(100) NOT NULL, 
    "last_name" varchar(100) NOT NULL, 
    "phone" varchar(100) NOT NULL, 
    "password" varchar(100) NOT NULL, 
    "type" varchar(100) NOT NULL, 
    "date_created" timestamp with time zone NOT NULL, 
    "active" varchar(100) NOT NULL);

Как мне это сделатьоператор создания и цикл включенных полей, чтобы убедиться, что они доступны в БД, к которой я подключен (используя операторы alter, которые я предполагаю, будетлучший путь)?

Большая заметка

Я работаю с Джанго всего несколько месяцев, но я вспоминаю документацию Джанго, в которой говорится, что это обычноЛучшая идея - добавить attriubute null = true к добавленным Model.fields , чтобы они просто автоматически добавлялись в базу данных при миграции.Я не уверен, если это проблема в моем случае, я просто пытаюсь найти решение, которое автоматически гарантирует, независимо от того, к какой базе данных я подключен, я полностью синхронизирован и нет ошибок SQL, указывающих, что поле не существует,даже когда я запускаю миграции.

До сих пор мне удавалось решить мои проблемы, очистив любую базу данных, к которой я подключен, и затем запустив python manage.py migrate на основе исходного файла миграции, но это не такправильное решение для производственного экземпляра, где я не могу сбросить все.

Мне нужны идеи, я думаю, что оператор alter table, основанный на строке, полученной из python manage.py sqlmigrate objects 0001, является лучшим, но я открыт для всего, что исправит мою проблему, поэтому у меня нетбеспокоиться об этом больше.

1 Ответ

0 голосов
/ 16 ноября 2018

Так же, как это отмечено, я использую пакет django-reset-migrations из PyPi после выполнения миграций, чтобы папка миграций не усложнялась и все сохранялось в одной миграции 0001_initial.py файл.

Решение вашей проблемы простое: прекратите это делать.

Сброс файлов миграции таким способом является продвинутой, потенциально опасной техникой. Это никогда не требуется, но может быть полезно в некоторых обстоятельствах. Папка миграции «усложнение» не является реальной проблемой, которую нужно решать, особенно для начинающего проекта.

Что делает его опасным, так это то, что он по замыслу стирает историю изменений, внесенных в ваши модели и базу данных. Поэтому, если вы запускаете его, когда база данных не полностью обновлена ​​- как вы, очевидно, сделали - вы удалили информацию, необходимую для этого. (В частности, когда вы сбрасываете миграции перед миграцией своей базы данных dev, вы удаляете файл, в котором указано, как добавить новый столбец.)

...