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

Я только что создалмодель прокси и был удивлен, чтоmanage.py makemigrations создает новый файл миграции сmigrations.CreateModel операция.

Прокси-модель не создает новую таблицу базы данных, это просто другой интерфейс Python для того же набора данных, и на самом делеmanage.py sqlmigrate my_app_label 0042 ничего не возвращает

Я думал, что это может быть использовано для создания модели проксиContentType но они создаются по требованию, если они не существуют.

Используется ли он для создания разрешений модели прокси? Есть6-летний открытый баг на разрешениях модели прокси, так что я не совсем уверен, как эта часть должна работать сейчас ...

Он использовалDjango 1.8 чтобы проверить это.

редактировать: уточнить,Django создает миграцию, которая ничего не делает для новых моделей прокси, поэтому мы бы не хотелиDjango не создавать миграцию в первую очередь, если она бесполезна?

Есть ли вариант использования, где было бы полезно провести миграцию?

Ответы на вопрос(2)

migrations генерируются, потому что базы данных затронуты иmigrations как Django сигнализирует об изменениях в базе данных. Структура не изменяется, но записи добавляются в (как минимум) две таблицы:

НовыйContentType добавлен вdjango_content_type для модели прокси.Разрешения, специфичные для модели Proxy, добавляются вauth_permission, Я предполагаю, что это всегда происходит, если прокси-сервер не использует одно и то же имя класса. Это, безусловно, происходит - мы на самом деле используем модель прокси для доступа к Пользователю, используя различные разрешения, не затрагивая модель пользователя по умолчанию.

Обе эти детали фактически отмечены в цепочке комментариев к проблеме, связанной с OP (например, комментарий # 31), потому что они вносят свой вклад в ошибку (то есть, что Django ищет разрешения в приложении, отличном от того, которое фактически генерируется вauth_permissions).

Решение Вопроса

но если вы откроете миграцию в своем редакторе, вы обнаружите, что это на самом деле пустая миграция! Вот пример

class Migration(migrations.Migration):
    dependencies = [
        ('stackoverflow', '0009_auto_20160622_1507'),
    ]

    operations = [
        migrations.CreateModel(
            name='MyArticle',
            fields=[
            ],
            options={
                'proxy': True,
            },
            bases=('stackoverflow.article',),
        ),
    ]

И если вы бежите./manage.py sqlmigrate myapp 0010 (это число, которое соответствует моей миграции выше), то, что вы получите, это то, что находится на следующей строке (ничего).

Это потому чтоfields раздел миграции пуст иoption включает в себяproxy = True, Этот параметр предотвращает любыеSQL от выполнения для этой миграции, и исходная таблица остается нетронутой.

Итак, вы можете спросить, почемуDjango потрудитесь создать пустую миграцию? Это потому, что прокси-модель может быть упомянута другой моделью в будущей миграции.

Ваш ответ на вопрос