У меня есть модель UserProfile
, которая относится к моей модели User
с OneToOneField
. Я также использую сигнал post_save
для автоматического создания UserProfile
, когда пользователь создан. Это отлично работает, когда вы создаете пользователя через администратора (где я использую встроенный), когда я получаю сообщение об ошибке с дублирующимся профилем. This answer recommends setting the primary key to be the OneToOneField referring to user.Как написать миграцию, чтобы изменить первичный ключ модели с ManyToManyField
Так что прежде:
class UserProfile(models.Model):
user = models.OneToOneField(settings.AUTH_USER_MODEL)
# ...
subjects = models.ManyToManyField(Subject, null=True, blank=True)
После
class UserProfile(models.Model):
user = models.OneToOneField(settings.AUTH_USER_MODEL, primary_key=True)
# ...
subjects = models.ManyToManyField(Subject, null=True, blank=True)
Я пытаюсь сделать это с помощью миграции в Django 1.7, но жизнь осложняется тем, что профиль имеет ряд ManyToManyField
- поэтому все они относятся к полю id
модели UserProfile
. С помощью makemigrations
создаются миграции для внесения пользователем первичного ключа и удаления старого поля id, но он игнорирует ManyToManyField.
В настоящее время я перехожу к кроличьей норе, используя множество операторов RunSQL
в процессе миграции, чтобы изменить сквозной стол для ManyToManyField
. Я только что нажал другую ошибку, где имя ограничения не одинаково в одной таблице, как другое.
Итак, мой вопрос: существует ли способ миграции Django, который будет выполнять работу по изменению таблицы сквозных, чтобы он ссылался на новый первичный ключ, обновляя все ограничения, ключи и т. Д.? Если нет, каков наилучший способ справиться с этой ситуацией?
Я использую Django 1.7 с MySQL.
Я бы сказал, что решение неверно. Ваш сигнал должен быть изменен, чтобы не пытаться сортировать повторяющиеся профили.Первичное ключевое решение просто кажется мне взломанным. –
@Kye - обработчик сигнала создает профиль ** до ** admin inline пытается создать профиль. Таким образом, обработчик сигнала должен был бы разработать пользователь, создаваемый администратором, чтобы знать, что администратор попытается создать пользователя - он не может просто проверить, не существует ли профиля в базе данных. Альтернативой было бы иметь встроенный тест администратора, если профиль уже существует до его создания, но это кажется мне взломанным. –
@HamishDowner выглядит как его ошибка: https://code.djangoproject.com/ticket/25012 – Anupam