InvalidBasesError: не удается разрешить базы для [<ModelState: 'users.GroupProxy'>]

Когда я запускаю тесты, я получаю эту ошибку при инициализации базы данных:

django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'users.GroupProxy'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)

Я создал этот прокси для модели contrib.auth Group, чтобы поместить его в свое приложение в admin django:

class GroupProxy(Group):
    class Meta:
        proxy = True
        verbose_name = Group._meta.verbose_name
        verbose_name_plural = Group._meta.verbose_name_plural

Итак, что я могу сделать, чтобы исправить эту проблему?

Ответы

Ответ 1

После многого рытья на этом единственное, что сработало для меня, было

comment out the offending apps, run migrations, then add them in again.

Просто обходной путь, но, надеюсь, это помогает кому-то.

Ответ 2

Я столкнулся с этой проблемой, и поскольку комментирование модели на самом деле не является решением, я обнаружил, что установка недокументированного auto_created = True в класс Meta заставит Django игнорировать его.

class GroupProxy(Group):

    class Meta:
        proxy = True
        auto_created = True

Ответ 3

Просто создайте каталог migrations в корне вашего приложения (так что users/migrations/ в вашем случае) и добавление пустого файла __init__.py может решить вашу проблему. По крайней мере, это было для меня, когда я получал ту же ошибку.

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

Почему Django создает файлы миграции для прокси-моделей?

Ваши тесты ищут эти миграции и не находят их.

Ответ 4

Вы пытались запустить manage.py makemigrations <app_label> в своем приложении перед запуском тестов?

Кроме того, проверьте, включено ли приложение, к которому вы пытаетесь подключиться к прокси-серверу, в INSTALLED_APPS.

Ответ 5

Проведя большую часть сегодняшнего дня, пытаясь решить эту ошибку самостоятельно, пройдя все мыслимые смеси "комментариев приложений", "отбрасывая таблицы" и отбросив все базы данных, я обнаружил, что моя проблема была вызвана простым отсутствием 'миграция' и файл __ init__.py внутри указанной папки.

Один из более старых ответов, который был прав, теперь уже не правильный, поскольку они исправили проблему, упомянутую здесь здесь.

Проверьте каждый каталог, содержащий модель, указанную в "init.py", и она должна исчезнуть.

Наверное, не решит каждый случай, но он помог мне.

Ответ 6

Я также столкнулся с этой проблемой (после выполнения некоторого сложного наследования модели). Одна из моих миграций содержала

migrations.CreateModel(
    name='Offer',
    fields=[
        # ...
    ],
    options={
        # ...
    },
    bases=('shop.entity',),
),

Я удалил модель shop.Entity полностью, но миграция ссылалась на нее в атрибуте bases. Поэтому я просто удалил bases=('shop.entity',), и он работает. Вероятно, это приведет к возможности миграции с самого начала, но, по крайней мере, позволяет дальше мигрировать.

Еще один совет: перейти непосредственно к коду джанго и проверить, что вызывает проблемы с "базами". Перейдите к django/db/migrations/state.py и добавьте точку останова:

try:
    bases = tuple(
        (apps.get_model(base) if isinstance(base, six.string_types) else base)
        for base in self.bases
    )
except LookupError:
    print(self.bases)  # <-- print the bases
    import ipdb; ipdb.set_trace()  # <-- debug here
    raise InvalidBasesError("Cannot resolve one or more bases from %r" % (self.bases,))

Ответ 7

Если это происходит только при запуске python manage.py test (возможно, потому, что вы уже выполнили необходимые миграции), вы должны явно сказать, что contrib.auth не должен мигрировать в MIGRATION_MODULES вашего модуля настроек.

MIGRATION_MODULES(
        'auth': "contrib.auth.migrations_not_used_in_tests",
)

Ответ 8

У меня была эта проблема после того, как я переименовал родительскую таблицу группы моих прокси-моделей. Я решил это:

  1. Удаление файла миграции, для которого было изменено имя родительской таблицы.
  2. Используя терминал postgres, я переименовал родительскую таблицу в ее прежнее имя.
  3. Снова запустили makemigrations и migrate

Ответ 9

Возможно, что удаление или создание модели в файле миграции происходит в неправильном порядке. Я испытал это в Django 1.7.8, когда базовой моделью была ДО производной модели. Замена порядка удаления модели устранила проблему.

Ответ 10

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