При обновлении до Django 1.8 (с zc.buildout) и запуске syncdb или переноса, я получаю это сообщение:
django.db.utils.ProgrammingError: relation "auth_user" does not exist
Одна из моих моделей содержит django.contrib.auth.models.User:
user = models.ForeignKey(
User, related_name='%(app_label)s_%(class)s_user',
blank=True, null=True, editable=False
)
Переход к Django 1.7 удаляет ошибку. Должен ли я включать объект User по-разному в Django 1.8?
Я исправлю это, сначала запустив auth, затем остальные мои миграции:
python manage.py migrate auth
python manage.py migrate
В моей среде я исправляю этот запуск makemigrations для всех приложений, имеющих отношения с django.contrib.auth.models:
manage.py makemigrations app_with_user_relation manage.py migrate
У меня также была та же проблема, что я решил ее использовать:
python manage.py migrate auth
python manage.py migrate
Затем migrate выполняет свою работу
Если вы используете герою, как я был запущен
heroku run python manage.py makemigrations
Это, скорее всего, даст вам сообщение о том, что теперь есть изменения. Игнорируйте это, затем запустите
heroku run python manage.py migrate
это даст вам некоторый результат, предполагающий, что что-то было сделано. Наконец запустите
heroku run python manage.py createsuperuser
Эта проблема содержится в запуске "makemigrations" для всех приложений, которые еще не были перенесены, то есть приложений, которые еще не имеют файла "initial_0001.py" в своем каталоге миграции.
Это сделано (в нашем случае мы используем make файл), выполнив для каждого из этих приложений:
manage.py makemigrations app_name
Как только это будет сделано, вы можете выполнить:
manage.py migrate
как обычно.
Основной причиной этого является то, что по какой-то причине
manage.py makemigrations
не всегда создает эти начальные миграции, если они еще не существуют. И это приводит к указанной ошибке.
Наоборот,
manage.py makemigrations app_name
всегда создает их (если их еще нет). К сожалению, я не могу понять причины этой асимметрии.
Чтобы устранить эту проблему, вот что я сделал:
1) Найдите в своем проекте все отношения с внешним ключом, такие как OneToOneField, ForeignKey и ManyToManyFields, включая любые повторно используемые приложения, которые ссылаются на auth.User или импортируют пользователя и устанавливают его в settings.AUTH_USER_MODEL, как указано выше. При минимальном использовании:
'auth.User'
2) Для всех моделей, которые имеют вышеизложенное, убедитесь, что модели имеют действительную миграцию django (а не юг). Если у них есть южные миграции, переименуйте каталог в migrations_south, а затем запустите команду makemigrations для этого приложения:
./manage.py makemigrations affected_app
Иногда есть папка миграции django под другим именем, а не по умолчанию migrations. В таких случаях укажите это через MIGRATION_MODULES в своих настройках .py:
MIGRATION_MODULES = {'filer': 'filer.migrations_django'}
Поскольку проблему трудно найти в более крупных проектах, я прокомментировал все пользовательские приложения в INSTALLED_APPS в settings.py и запустил тестовую команду, так как она запустит миграцию и попытается заново создать базу данных для вас:
./manage.py test
Похоже, это исправило это для меня. Я не уверен, что шаг 1 является обязательным или просто передовой практикой. Но вам определенно нужно преобразовать приложения в миграцию.
Ура!
PS. Будьте готовы к тому, что приходит в Django 1.9. Команда syncdb будет удалена. Унаследованный метод синхронизации приложений без миграции удаляется, а миграция является обязательной для всех приложений.
Попробуйте обратиться к пользователю с помощью
from django.conf import settings
user = models.ForeignKey(settings.AUTH_USER_MODEL, related_name='%(app_label)s_%(class)s_user', blank=True, null=True, editable=False)
Я перенес проект старого Django 1.6 в Django 1.8, и ранее мы использовали syncdb для миграции базы данных, и мы сделали не первоначальные шаги миграции для всех приложений в нашем проекте. С Django 1.8 вам понадобятся рабочие миграции баз данных. Выполнение
manage.py makemigrations <app_name>
для всех приложений нашего проекта были устранены наши проблемы.
Возможно, вы нашли ответ и решили проблему, но я хотел бы указать, что в моем случае вышеуказанная проблема была решена путем сброса базы данных и повторного создания ее с полными привилегиями пользователей. Я смог это сделать, потому что я работаю над непроизводственной средой, но делать это в промежуточной среде - это не очень хорошая идея, поэтому будьте осторожны.
Im, использующий python 2.7.12, и следующие спецификации моего virtualenv:
Django==1.10.5
django-crispy-forms==1.6.1
django-registration-redux==1.4
djangorestframework==3.5.3
olefile==0.44
packaging==16.8
Pillow==4.0.0
psycopg2==2.6.2