Миграция без ошибок, все еще без изменений в базу данных - PullRequest
0 голосов
/ 08 февраля 2020

Это моя модель.

class Otp(models.Model):   
user = models.OneToOneField('CustomUser', on_delete=models.CASCADE)
onetime = models.CharField(max_length=25, default=calculated, unique=True)
link = models.UUIDField(default=uuid.uuid4, unique=True)
created_at = models.DateTimeField(auto_now_add=True)

Я только что добавил столбец "ссылка". Отлично работает в моей среде разработки.

Когда на моем сервере я go inte venv и запускаю 'makemigrations', вижу изменения. Затем «мигрировать» и все применяется.

Теперь, когда я захожу на страницу, использующую таблицу, я получаю «столбец не существует».

I go inte postgres и проверяю стол. Изменений не применено. Новый столбец отсутствует.

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

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

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

РЕДАКТИРОВАТЬ с обновлением моего расследования. Мое соединение с базой данных установлено в настройках в production.py для postgres. Мой development.py - это sqlite.

Так что теперь я проверил db для sqlite на моем сервере. И, конечно же, миграция применяется к sqlite, а не postgres.

, почему он вдруг выбрал sqlite?

Так я применяю изменения.

1. Make changes in models.py for app
2. Activate venv to be able to run migrations
3. Run 'python manage.py makemigrations APPNAME'
4. Run 'python manage.py migrate APPNAME'

Итак, что определяет запуск миграций в направлении sqlite, а не postgres?

1 Ответ

0 голосов
/ 08 февраля 2020

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


В ответ на ваше последнее изменение убедитесь, что вы запускаете экземпляр Django на своем сервере, используя ваши настройки производства. Исходя из того, что вы описали, я предполагаю, что в вашем файле wsgi.py есть строка, напоминающая

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myapp.development")

Django, в которой нет понятия «разработка и производственные настройки». Он знает только о том, как загрузить модуль настройки, который вы ему сообщаете.

При работе в производственной среде вам необходимо явно указать использование ваших «производственных настроек». Это проще всего сделать, установив переменную среды DJANGO_SETTINGS_MODULE в путь Python модуля настроек. Обратите внимание, что это должно быть выполнено веб-сервером, на котором запущено ваше приложение Django. Просто ssh входящий и работающий export DJANGO_SETTINGS_MODULE=myapp.production не обрежет это.

Обычной практикой является настройка конечной точки wsgi.py по умолчанию на производственные параметры и явный выбор параметров разработки на локальном компьютере, например, с помощью

$ ./manage.py --settings=myapp.development_settings <command>
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...