Как я могу исправить пользовательскую модель, сохраняя существующие данные? - PullRequest
Новая
       36

Как я могу исправить пользовательскую модель, сохраняя существующие данные?

0 голосов
/ 03 мая 2018

У меня есть большое приложение Django, в настоящее время пытающееся обновить его с 1.6 до 1.7 (были попытки перейти прямо на 1.11, но это было слишком много проблем, поэтому я планирую делать это по одному несовершеннолетнему за раз).

Я следую инструкциям Upgrade from South и удалил все предыдущие миграции, но не могу заставить makemigrations работать. В настоящее время проблема заключается в том, что модель auth.User была исправлена ​​для включения двух новых полей: 

User.add_to_class('profile',
                  models.ForeignKey('access.Profile', null=True, blank=True,
                                    related_name='user_foreignkey'))
User.add_to_class('profiles', 
                  models.ManyToManyField('access.Profile', null=True,
                                         blank=True))

Этот патч был сделан в отдельном приложении. Если я просто оставлю его там, где он есть, я получу следующую ошибку при запуске python manage.py makemigrations: 

ValueError: Lookup failed for model referenced by field auth.User.profiles:
access.Profiles

Я попытался переместить вызовы add_to_class в тот же файл, где определен Profile (после определения), но получил ту же ошибку. Я также попытался изменить синтаксис с 'access.Profile' на Profile, но безрезультатно. Есть ли что-то еще, что могло бы сделать эту работу?

Если нет, поскольку я добавляю поля в модель, я полагаю, что правильным подходом было бы расширение модели AbstractUser, как предлагает в этом руководстве . Проблема в том, что новая начальная миграция создаст таблицу access_user вместо использования существующей auth_user. Было бы безопасно просто переименовать auth_user в access_user и подделать миграцию?

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

1 Ответ

0 голосов
/ 03 мая 2018

тл, др; Я удалил auth миграций и снова запустил makemigrations, что, похоже, решило проблему.

Я решил попробовать вариант 2. Я удалил патчи add_to_class, создал новый class User(AbstractUser) с новыми полями, удалил все существующие миграции и снова запустил makemigrations. Я получил точно такую ​​же ошибку, которая не имела смысла, потому что больше не было кода, связывающего auth.User с Profile, поэтому я решил исследовать миграцию auth. Я побежал 

$ python migrate --list settings=settings.mysettings

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

В руководствах по "как сбросить все миграции" не упоминаются сторонние установленные приложения, но благодаря этой теме Я знал, где Django хранил аутентификации миграции, поэтому я удалил их обоих (начальный и подозрительный) и переупорядочил INSTALLED_APPS так, что access теперь до django.contrib.auth. Затем снова запустил makemigrations и успешно прошел миграцию access и auth.

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

Было бы неплохо иметь более интуитивно понятный способ сброса всех существующих миграций, а не только тех, которые находятся в вашем репо. Но опять же, я не думаю, что add_to_class патчи - это правильный способ сделать то, что мы хотели.

...