Проблемы миграции при добавлении ForeignKey в модель

В настоящее время у меня есть сайт, на котором размещены приложения и база данных пользователей. Теперь я хочу соединить их, чтобы у приложений могли быть авторы (т.е. пользователи).

Обновление: ниже добавлено еще несколько важных деталей, и я использую django-registration.

Следуя этому, а также документам Django, я начал с добавления строки author к моей модели приложений:

from django.contrib.auth.models import User

class App(models.Model):
    name = models.CharField(max_length=200)
    ...
    author = models.ForeignKey(User)

Однако, когда я захожу в свои приложения из администратора django, я получаю сообщение об ошибке DatabaseError at /admin/apps/app/ ... такого столбца нет: apps_app.author_id

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

Я использую South для миграции и побежал

./manage.py schemamigration apps --auto

Для одноразового значения я установил «ноль», так как он ожидает int()

./manage.py migrate apps

Это не сработало, поэтому я сделал

./manage.py migrate apps --fake

Затем снова предыдущая команда, без --fake.

Кроме того, согласно связанному вопросу SO, я должен также создать class User(User) в apps/models.py?

Обновление 2 Я только что создал новое приложение django (не путать .manage.py startapp... с моим объектом "приложение"). Я прошел этапы создания, добавив этот внешний ключ, и он работал нормально. Мой единственный вывод из этого заключается в том, что это должна быть проблема миграции на юг, а не что-то не так с моим кодом.


person Adam Grant    schedule 04.10.2012    source источник


Ответы (2)


Я пробовал это как на своем локальном компьютере, так и на сцене, и это лучшее решение, которое я мог придумать.

Поскольку по какой-то причине Юг не «видит», что столбец автора нужно добавить в таблицу приложений, существует вариант ручной миграции схемы с флагом --add-field.

Я сделал:

/manage.py schemamigration apps --add-field app.author

затем

./manage.py migrate apps

Если последний не работает, попробуйте

./manage.py migrate apps --fake 000x

где 000x — номер миграции. Вы можете получить это из вывода первого шага.

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

person Adam Grant    schedule 04.10.2012

./manage.py перенос приложений

Это не сработало, поэтому я сделал

Как вы имеете в виду, что это не сработало? Какую ошибку вы получили?

Для подобных ситуаций я обычно создаю FK с null=True, запускаю эту миграцию, а затем создаю миграцию данных, которая заполнит FK.

Кроме того, согласно связанному вопросу SO, я должен также создать класс User(User) в apps/models.py?

Если вы хотите связать автора с пользователем авторизации django, просто импортируйте его из django.contrib.auth.models. В противном случае да, вам нужна модель User (или лучше Author), которая будет подклассом django.db.models.Model, а не User

person bmihelac    schedule 04.10.2012
comment
Хорошо, я забыл упомянуть об этом. Я импортирую django.contrib.auth.models. Секунду, я проверю ваше решение. - person Adam Grant; 04.10.2012
comment
Все еще получаю ту же ошибку, хотя мне интересно, если бы не использование null=True в первые несколько раз необратимо испортило базу данных. Ошибка с юга была/является django.db.utils.DatabaseError: таблица _south_new_apps_app уже существует - person Adam Grant; 04.10.2012
comment
Нет, плевать на эту теорию. Я пытался просто придумать для него новое имя, appauthor, но теперь оно говорит no such column: apps_app.appauthor_id. - person Adam Grant; 04.10.2012