Django 1.8 не работает django.db.utils.ProgrammingError: отношения "auth_user" не существует

Ответ 1

Мне не понравилась идея комментировать/раскомментировать код, поэтому я попробовал другой подход: я перенял "вручную" некоторые приложения, а затем запустил django-admin.py migrate для остальных. После удаления всех файлов *.pyc моя последовательность команд была:

$ django-admin.py migrate auth
$ django-admin.py migrate contentypes
$ django-admin.py migrate sites
$ django-admin.py migrate MY_CUSTOM_USER_APP
$ django-admin.py migrate

где MY_CUSTOM_USER_APP - это имя приложения, содержащего модель, которую я установил AUTH_USER_MODEL в мой файл settings.

Надеюсь, это поможет. Кстати, странно, что лучший способ синхронизировать ваш db в Django 1.8 настолько сложный. Интересно, не хватает ли я чего-то (я не очень хорошо знаком с Django 1.8, я работал со старыми версиями)

Ответ 2

Всегда переносите db с python manage.py makemigrations, а затем python manage.py migrate в более новые версии. Для ошибки выше, если в первый раз вы переносите свою базу данных, используйте python manage.py migrate --fake-initial. См. Docs https://docs.djangoproject.com/en/1.9/ref/django-admin/#django-admin-migrate

Ответ 3

Работа с Django 1.10 Я обнаружил другое решение: Мое приложение называется "web", и сначала я вызываю:

python manage.py makemigrations web

то я вызываю:

python manage.py makemigrations auth

то я вызываю:

python manage.py migrate

Пораженный: ЭТО РАБОТАЕТ!:) Кажется, auth искал AUTH_USER_MODEL "web.UserProfile" и отношение с именем web_user_profile, и он не нашел его, следовательно, ошибку. С другой стороны, вызов makemigrations web сначала создает требуемое отношение, прежде чем auth сможет проверить и предупредить его не там.

Ответ 4

У меня была такая же проблема, и я часами стучал головой, пытаясь найти решение, которое было скрыто в комментариях. Моя проблема заключалась в том, что CircleCI не смог запустить тесты из-за этой ошибки. И я подумал, что мне нужно будет начать новую работу с новой и пустой БД. Но у меня такие же ошибки. Все было похоже на "auth", "contenttypes" и "sites".

Я читал этот и этот, а также this, а также . Для меня не было решений.

Итак, после того, как я уничтожил свою БД и создал новую, единственным решением, которое я нашел, чтобы полностью избежать этих django.db.utils.ProgrammingError, было следующее:

• Прокомментируйте весь код, относящийся к модели User.
• Удалить все .pyc файлы в моем проекте! find . -name "*.pyc" -exec rm -- {} + Спасибо @max!
• run ./manage.py migrate (без подделки, без подделки-инициализации, без миграции 'auth' или 'contenttypes' до, juste plain migrate.
• Раскомментируйте приведенный выше код и снова запустите миграцию!

My INSTALLED_APP:

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.contenttypes',
    'django.contrib.sites',
    'django.contrib.auth',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
    'mptt',
    'djangobower',
    'honeypot',
    'django_hosts',
    'leaflet',
    'multiselectfield',
    'corsheaders',
    'rest_framework_swagger',
    'allauth',
    'allauth.account',
    # 'allauth.socialaccount',
    # 'allauth.socialaccount.providers.twitter',
    # 'allauth.socialaccount.providers.facebook',
    'project.<app_name>',
)

Ответ 5

В моем случае эта ошибка появлялась, когда драйвер postgresql смог подключиться к базе данных, но предоставленный пользователь не имеет доступа к схеме или таблицам и т.д. Вместо того, чтобы сказать, что разрешение запрещено, показанная ошибка говорит о том, что запрашиваемая таблица базы данных не найдена. Как правило, в такой ситуации команда migrate также django_migrations ошибкой с аналогичной ошибкой при django_migrations создать таблицу django_migrations.

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

Ответ 6

Удаление файлов миграции, связанных файлов .pyc и просто для безопасности всех файлов .pyc с помощью следующих команд не решило мою проблему.

$ find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
$ find . -path "*/migrations/*.pyc"  -delete
$ find . -name "*.pyc" -exec rm -- {} +

То, что в итоге решило мою проблему, заключалось не в очистке кэшей, а в том, что у меня была функция, выполняющая запрос в качестве параметра функции по умолчанию. В init, что делают команды, такие как makemigrations и migrate перед выполнением, кажется, что django (возможно, атрибут python?) Инициализирует все параметры по умолчанию.

Так как моя база данных была полностью пустой (мне нужно было выполнить migrate --run-syncdb для воссоздания таблиц), когда указанный ниже параметр по умолчанию был инициализирован, он выполнил запрос к пустой базе данных, который впоследствии завершился migrate --run-syncdb.

изменить это:

def generate_new_addresses(number=1, index=None, wallet=get_active_wallet()):
   ...
   ...
   return

чтобы:

def generate_new_addresses(number=1, index=None, wallet=None):
   if not wallet:
      wallet = get_active_wallet()
   ...
   ...
   return

Ответ 7

У меня была та же проблема, но моей основной причиной был файл __init__.py в одной из папок миграции, который был удален из исходного кода, но не локально (что приводило к ошибкам "Не на моей машине").

Папкам миграции все еще нужны файлы __init__.py, даже с Python 3.

Ответ 8

Ошибка в основном потому, что db (postgres или sqlite) не нашли отношения, для которого вы вставляете или выполняете CRUD. Решение состоит в том, чтобы сделать миграции

python manage.py makemigrations <app_name> python manage.py migrate