django.db.migrations.exceptions.InconsistentMigrationHistory


85

Коли я запускаю python manage.py migrateсвій проект Django, я отримую таку помилку:

Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/home/hari/project/env/local/lib/python2.7/site-     packages/django/core/management/__init__.py", line 363, in execute_from_command_line
utility.execute()
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 355, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 86, in handle
executor.loader.check_consistent_history(connection)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/db/migrations/loader.py", line 298, in check_consistent_history
connection.alias,
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

У мене є модель користувача, як показано нижче:

class User(AbstractUser):
    place = models.CharField(max_length=64, null=True, blank=True)
    address = models.CharField(max_length=128, null=True, blank=True)

Як я можу вирішити цю проблему?


4
перш за все видаліть усі таблиці з бази даних, видаліть усі файли з папки міграцій, крім init.py, потім запустіть migrate
Exprator

як видалити всі таблиці?
Харі Крішнан

який db ти використовуєш?
Exprator

так я видалив його, і зараз він працює.
Харі Крішнан

Для мене проблема полягала в тому, що я мав міграцію, яка залежала 'ipn', '__latest__'. Я просто перевірив порядок чи міграції, до яких застосовано select * from django_migrations, потім змінив __latest__, 'ipn', '0007_auto_20160219_1135'і проблема зникла.
Рубен Алвес

Відповіді:


47

Ваша таблиця django_migrations у вашій базі даних є причиною невідповідності, і видалення всіх міграцій лише з локального шляху не буде працювати.

Вам потрібно скоротити таблицю django_migrations зі своєї бази даних, а потім спробувати застосувати міграції ще раз. Це має спрацювати, але якщо це не стане, знову запустіть макеграцію, а потім перейдіть.

Примітка: не забудьте зробити резервну копію даних.


5
Не працював. Коли я намагався мігрувати, він скаржився, що відношення вже існує. Зверніть увагу, що ви можете скоротити таблицю django_migrations за допомогою цієї команди:> python shell.py shell `` `з django.db import connection cursor = connection.cursor () cursor.execute (" TRUNCATE TABLE django_migrations ")` `І ви можете переглянути таблиця міграції така: `` з імпорту django.db.migrations.recorder MigrationRecorder MigrationRecorder.Migration.objects.all () ``
Almenon,

2
Це жахлива ідея з великою ймовірністю втрати даних. Дивіться мою відповідь нижче.
tbm

107

Оскільки ви використовуєте власну модель користувача, ви можете спочатку залишити коментар

INSTALLED_APPS = [
...
#'django.contrib.admin',
...
]

у налаштуваннях Installed_Apps. Тоді біжи

python manage.py migrate.

Коли закінчується, коментуйте

'django.contrib.admin'

Так, це вирішило мою проблему! Мене змінили за замовчуванням користувацькою моделлю на Абстрактну модель користувача, і після всіх міграцій виникла помилка. Але коли я спробував це, вирішив мою проблему!
mevaka

29
У мене це не працює. Повідомлення про помилку "Немає програми для встановлення з адміністратором ярликів", чи потрібно спочатку видаляти всі файли в міграціях? хтось знає, як це вирішити? Дякую ~
Спритна лапаN

2
Перевірте відповідь користувача 9414732 нижче.
Рексцирус

16
не забудьте шлях коментарів ('admin /', admin.site.urls) в urls.py
Володимир

72

Почнемо з вирішення проблеми з більшістю відповідей на цій сторінці:

Вам ніколи не доведеться скидати базу даних, якщо ви правильно використовуєте систему міграції Django, і ви ніколи не повинні видаляти міграції після їх введення

Зараз найкраще рішення для вас залежить від ряду факторів, які включають, наскільки ви досвід роботи з Django, який рівень розуміння вашої системи міграції та наскільки цінні дані у вашій базі даних.

Коротше кажучи, можна усунути будь-яку помилку міграції двома способами.

  1. Візьмемо ядерний варіант. Увага: це варіант, якщо ви працюєте самостійно. Якщо інші люди залежать від існуючих міграцій, ви не можете просто їх видалити.

    • Видаліть усі свої міграції та відновіть новий набір за допомогою python3 -m manage makemigrations. Це має усунути будь-які проблеми, пов’язані із залежностями або невідповідностями в процесі міграції.
    • Відкиньте всю базу даних. Це дозволить усунути будь-які проблеми, пов’язані з невідповідностями між фактичною схемою бази даних та схемою, яку ви повинні мати на основі вашої історії міграції, а також усуне всі проблеми, пов’язані з невідповідністю між історією міграції та попередніми файлами міграції [це те, що на що InconsistentMigrationHistoryскаржиться].
    • Відтворіть схему бази даних за допомогою python3 -m manage migrate
  2. Визначити причину помилки і усунути її, тому що (говорячи від досвіду) причина майже напевно що - то нерозумно ви зробили. (Як правило, внаслідок нерозуміння того, як правильно використовувати систему міграції). На основі помилки, яку я спричинив, є три категорії.

    1. Невідповідність файлам міграції. Це досить поширене явище, коли над проектом працює кілька людей. Сподіваємось, ваші зміни не суперечать іmakemigrations --merge можуть вирішити цю, інакше комусь доведеться відкотити свої міграції до точки розгалуження, щоб вирішити цю проблему.
    2. Невідповідність вашої схеми та історії міграції. Для управління цим хтось повинен або відредагувати схему бази даних вручну, або видалити міграції. Якщо вони видалили міграцію, скасуйте їх зміни та кричіть на них; ти ніколи не повинен видаляти міграції, якщо інші залежать від них. Якщо вони редагували схему бази даних вручну, скасуйте їх зміни, а потім кричіть на них; Django керує схемою бази даних, ніхто інший.
    3. Невідповідність між історією міграції та файлами міграцій. [Це InconsistentMigrationHistoryпроблема, від якої страждає запитувач, та та, від якої я страждав, коли потрапив на цю сторінку]. Для управління цим хтось або переплутався з django_migrationsтаблицею вручну, або видалив міграцію після її застосування. Щоб вирішити цю проблему, вам доведеться з’ясувати, як виникла невідповідність, і врегулювати її вручну. Якщо схема вашої бази даних правильна, і неправильна лише ваша історія міграції, ви можете вручну відредагувати django_migrationsтаблицю, щоб вирішити цю проблему. Якщо ваша схема бази даних неправильна, вам також доведеться вручну відредагувати її, щоб привести її у відповідність із тим, якою вона повинна бути.

Виходячи з вашого опису проблеми та вибраної вами відповіді, я припускаю, що ви працюєте поодинці, новачок у Django і не дбаєте про ваші дані. Тож ядерний варіант може підійти саме вам.

Якщо ви не в такій ситуації, і вищезазначений текст виглядає як тупік, то я пропоную запитати у до списку розсилки користувача Django . Там є дуже корисні люди, які можуть допомогти провести вас через вирішення конкретного безладу, в якому ви перебуваєте.

Вірте, ви можете усунути цю помилку, не ставши ядерною!


1
Для зацікавлених: У моєму випадку я створив тимчасову міграцію для створення таблиць у програмі B, поки я чекав, поки колега закінчить власні міграції, щоб перемістити таблиці з програми A у програму B. Коли мій колега закінчив, я повернув свою тимчасової міграції та пішов застосовувати міграції. Помилка бама. Я не тільки забув застосувати свою тимчасову міграцію, але і зумів назвати тимчасову міграцію такою ж, як і фактичну. До системи міграції міграція програми B, 0001_initialяка залежала від 00XX_autoміграції програми A, була якось застосована до її залежності!
Ефір

2
Настільки жахливим, як і все це звучить, його було легко вирішити. У моїй базі даних була правильна схема, тому все, що мені потрібно було зробити, - це вручну додати 'A' '00XX_auto'до django_migrationsтаблиці, щоб моя історія відображала, що зміни в цій міграції були застосовані. Складний, але не такий важкий, як тільки ви вирішите проблему.
Ефір

Ви не можете просто видалити міграції, необхідно видалити pycache теж
JonPizza

Я потрапив у цей розсольник, тому що мав купу таблиць вихідних даних, які не є Django, тому більшість моїх моделей були managed = Falseв них. Коли я вирішив дозволити ORM робити свою справу і переходити до керованих моделей (як спосіб запуску моїх тестів), тоді почалося все моє "задоволення".
CJM

Вам слід повністю видалити міграції, якщо ваша команда вирішить збити 0001 до 0230 або, як би у вас не було сотень-міграцій: ви скоюєте стиснуту міграцію, чекаєте, щоб CI / CD застосував її, і як тільки prod повністю наздожене, ви видалите оригінальні файли 0001 _... через 0230 _..., оскільки вони вже нічого не роблять, і ви знову оновлюєте міграції сквош, щоб більше replacesнічого про це не говорити . Зберігання старих міграцій навколо зробить для вашої команди пекло життя лише тоді, коли комусь потрібно з’ясувати, яка з безлічі 0002 міграцій є справжньою.
Майк 'Помакс' Камерманс

37

Ось як це правильно вирішити.

Виконайте такі дії у папці міграцій у проекті:

  1. Видаліть файли _pycache_ та 0001_initial.
  2. Видаліть db.sqlite3 з кореневого каталогу (будьте обережні, всі ваші дані зникнуть).
  3. під час запуску терміналу:
      python manage.py makemigrations
      python manage.py мігрує

Вуаля.


1
Що робити, якщо ми не хочемо видаляти та переходимо до виробничого режиму. Також я не використовую sqllite, це MySQL на нашому сервері. Який найкращий метод без втрати даних.
Bishwas Bhandari

33

Це трапилося зі мною в новому проекті після того, як я додав власну модель користувача відповідно до рекомендацій у документах django.

Якщо ви починаєте новий проект, настійно рекомендується встановити власну модель користувача, навіть якщо вам достатньо стандартної моделі користувача.

Ось що я зробив для вирішення проблеми.

  1. Видаліть базу даних db.sqlite3.
  2. Видаліть папку програми / міграції.

Для @jackson тимчасово коментуйте django.contrib.admin.

INSTALLED_APPS = [
...
#‘django.contrib.admin’,
...
]

Також прокоментуйте сайт адміністратора в urls.py:

urlpatterns = [
    path('profile/', include('restapp.urls')),
    #path('admin/', admin.site.urls),
]

Якщо ви не прокоментуєте шлях ('admin /'), ви отримаєте помилку "LookupError: немає встановленої програми з міткою" admin "" під час запуску

python manage.py migrate

Після завершення міграції розкоментуйте обидва вищезазначені.


26

Проблема

django.db.migrations.exceptions.InconsistentMigrationHistory: Міграція admin.0001_initial застосовується до його облікового запису залежності.0001_initial у базі даних за замовчуванням.

Отже, ми можемо перенести базу даних без адміністратора (admin.0001_initial), по-перше.

Після перенесення залежності виконайте команди для перенесення admin.0001_initial.

Рішення

  1. видаліть 'django.contrib.admin' з INSTALLED_APPS в settings.py.
  2. виконувати команди:

Ім'я програми Python manage.py makemigrations

Python manage.py мігрує ім'я програми

  1. додати 'django.contrib.admin' до INSTALLED_APPS у файлі settings.py.
  2. виконувати команди ще раз:

Ім'я програми Python manage.py makemigrations

Python manage.py мігрує ім'я програми


7
Для мене видалення 'django.contrib.admin' з INSTALLED_APPS і запуску макеграцій призводить доLookupError: No installed app with label 'admin'.
Шимон Пшедвойський

4
перейдіть на urls.py і прокоментуйте URL-адреси з адміністратором
Гаутам Кумар

2

просто видаліть файл sqlite або запустіть змивання databse 'python manage.py flush', а потім запустіть команди makemigrations та migrate відповідно.


2

коли ви створюєте новий проект Django і запускаєте

python manage.py мігрує

Django створить для вас 10 таблиць за замовчуванням, включаючи одну таблицю auth_user і дві починаються з auth_user.

коли ви хочете створити користувацьку модель успадкування від AbstractUser, ви зіткнетеся з цією проблемою із повідомленням про помилку наступним чином:

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

Я вирішую цю проблему, скинувши всю базу даних, і створюю нову. І це замінило три згадані мною таблиці.


2
Гаразд, а що, якщо я не хотів би скидати базу даних? Чи є доступне рішення?
Юліан Пінзару

2

Перш ніж виконувати будь-які інші дії, створіть резервну копію бази даних. Потім знову створіть резервну копію.

Видаліть будь-який спеціальний код користувацької моделі, відключіть власну модель та додаток у налаштуваннях, а потім:

python manage.py dumpdata auth --natural-primary --natural-foreign > auth.json
python manage.py migrate auth zero  # This will also revert out the admin migrations

Потім додайте власну модель, встановіть її в налаштуваннях і знову ввімкніть програму. Переконайтеся, що у вас ще немає міграцій у цій програмі.

Тоді:

python manage.py makemigrations <your-app>
python manage.py migrate
python manage.py loaddata auth.json  # Assumes your user-model isn't TOO dissimilar to the standard one.

Готово!


2

Які вирішуються коментуючи це до міграції в settings.py 'django.contrib.admin' і в urls.py, ('admin/', admin.site.urls). коментувати після міграції


поштовий індекс (заміна) у формі сценарію та зверху, де код починається, кожен блок починається з імені файлу, що представляє сценарій. Те, як ви розмістили свою відповідь, мене бентежить.
ZF007

@ ZF007 Вибачте за плутанину. Я трохи новачок у StackOverflow, тому я не розумів, як опублікувати відповідь
NaSir HuSSaiN

1

Спочатку видаліть усі міграції та файли db.sqlite3 та виконайте такі дії:

$ ./manage.py makemigrations myapp 
$ ./manage.py squashmigrations myapp 0001(may be differ)

Видаліть старий файл міграції і нарешті.

$ ./manage.py migrate

1

По суті, ваша помилка:

Migration "B" is applied before its dependency "A" on database 'default'.

Перевірка розумності : Спочатку відкрийте базу даних і перегляньте записи в таблиці 'django_migrations'. Записи слід перераховувати в хронологічному порядку (наприклад: A, B, C, D ...).

Переконайтеся, що назва міграції "A", вказана в помилці, відповідає назві міграції "A", зазначеної в базі даних. (Вони можуть відрізнятися, якщо ви раніше, вручну редагували, видаляли або перейменовували файли міграції)

Щоб виправити це , перейменуйте міграцію А. або в базі даних, або перейменуйте ім'я файлу. АЛЕ переконайтесь, що зміни збігаються з тим, що інші розробники у вашій команді мають у своїх базах даних (або зміни збігаються з тими, що містяться у вашій виробничій базі даних)


1

Якщо ви працюєте над порожньою базою даних, швидке виправлення може запустити міграції для програми облікового запису перед будь-якими іншими міграціями додатків.

$ ./manage.py migrate account

І потім:

$ ./manage.py migrate

1

Порядок INSTALLED_APPSвидається важливим. Якщо ви завжди ставите свої останні роботи зверху / на початку списку, вони завжди будуть завантажені належним чином стосовно django.contrib.admin. Переміщення моїх робіт на початок INSTALLED_APPSсписку вирішило цю проблему для мене. Причиною того, що рішення Кун Ши могло спрацювати, може бути, це запустило міграції в іншому порядку.


0

Якщо цей виняток виявився під час спроби створити власну модель користувача замість стандартної, дотримуйтесь цієї інструкції,
я знайшов свою проблему вирішеною, дотримуючись цієї інструкції крок за кроком:

  1. Створіть власну модель користувача, ідентичну для auth.User, зателефонуйте їй User (стільки таблиць багато-до-багатьох залишаються однаковими) і встановіть db_table = 'auth_user' (тому вона використовує ту саму таблицю)
  2. Киньте всі свої міграції
  3. Відтворіть новий набір міграцій
  4. Пожертвуйте куркою, можливо, двома, якщо ви стурбовані; також зробіть резервну копію бази даних
  5. Зрізати таблицю django_migrations
  6. Підроблено - застосовуйте новий набір міграцій
  7. Видаліть db_table, внесіть інші зміни до власної моделі, згенеруйте міграції, застосуйте їх

Настійно рекомендується робити це в базі даних, яка застосовує обмеження зовнішнього ключа. Не пробуйте це на SQLite на своєму ноутбуці і очікуйте, що він буде працювати на Postgres на серверах!


Не могли б ви додати до своєї відповіді короткий зміст статті або посилання на неї?
Коллін М. Барретт,

0

Якщо встановити AUTH_USER_MODE L у settings.py так:

AUTH_USER_MODEL = 'custom_user_app_name.User'

Вам слід прокоментувати цей рядок перед запуском команд makemigration і migrate . Тоді ви можете знову прокоментувати цей рядок.


3
На жаль, це призводить до помилок для мене, наприклад:accounts.CustomUser.groups: (fields.E304) Reverse accessor for 'CustomUser.groups' clashes with reverse accessor for 'User.groups'. HINT: Add or change a related_name argument to the definition for 'CustomUser.groups' or 'User.groups'.
Шимон Пшедвойський

0

коли ви створюєте новий проект і не маєте додатків, ви запускаєте

python manage.py migrate

Django створить 10 таблиць за замовчуванням.

Якщо ви хочете створити клієнтську модель користувача, яка успадковується AbstractUserпісля цього, ви зіткнетеся з цією проблемою як таке повідомлення:

django.db.migrations.exceptions.InconsistentMigrationHistory: Міграція admin.0001_initial застосовується до його облікового запису залежності.0001_initial у базі даних за замовчуванням.

нарешті, я скидаю всі свої бази даних і запускаю


0

Я зіткнувся з цим при переході з Wagtail 2.0 на 2.4, але бачив це ще кілька разів, коли стороння програма стискає міграцію після вашої поточної версії, але до версії, на яку ви мігруєте.

Шокуюче простим рішенням у цьому випадку є принаймні:

./manage.py migrate
./manage.py makemigrations
./manage.py migrate

тобто запустити одну міграцію, перш ніж намагатись зробити макеграцію.


0

Окрім помилок користувача, є ще одна причина, яка може призвести до такого роду проблем: відома проблема з Django, коли йдеться про зімкнуті міграції.

У нас є низка міграцій, які чудово працюють у Python 2.7 + Django 1.11. Бігmakemigrations абоmigrate завжди працює як слід тощо, навіть (з метою тестування), коли база даних щойно відтворена.

Однак, коли ми переносимо проект на Python 3.6 (наразі використовується той самий Django 1.11), я застряг, намагаючись зрозуміти, чому однакові міграції застосовуються чудово лише при першому запуску. Після цього будь-яка спроба запустити makemigrationsабо навіть просто migrateпризводить до помилки:

django.db.migrations.exceptions.InconsistentMigrationHistory

де міграція foo.0040-thingзастосовується до її залежностіfoo.0038-something-squashed-0039-somethingelse (у нас трапляється лише одна стиснена міграція ... решта набагато простіша).

Якийсь час мене хвилювало, чому це трапляється лише на Python 3. Якщо БД справді суперечлива, це повинно відбуватися постійно. Те, що міграції, здається, спрацьовують чудово при першому застосуванні, однаково бентежить.

Після довгих пошуків (включаючи поточну тему запитань та відповідей), я натрапив на згаданий звіт про помилки Django . Наша міграція сквошу справді використовувала bпрефікс у replacesрядку (наприклад,replaces = [(b'', 'foo.0038-defunct'),.......]

Як тільки я видалив bпрефікси з replacesрядка, все працювало нормально.


0

Ця проблема виникатиме більшу частину часу, якщо ви продовжите користувальницьку модель після початкової міграції. Оскільки кожного разу, коли ви розширюєте користувача Abstract, він створюватиме основні поля, які були присутні в моделі, як-от електронна пошта, ім'я та ін.

Навіть це стосується будь-якої абстрактної моделі в django.

Тож дуже просте рішення для цього - це створити нову базу даних, потім застосувати міграції, або видалити [Ви всі дані в цьому випадку буде видалено.] Ту саму базу даних і повторно застосувати міграції.


0

перш за все резервне копіювання даних. (скопіюйте свій файл db).

видаліть sqlite.db, а також папку міграції .

потім виконайте такі команди:

./manage.py makemigrations APP_NAME
./manage.py migrate APP_NAME

після видалення файлу DB та папки міграції переконайтеся, що після команд міграції напишіть назву програми.


0

Добре, перш ніж робити щось дивне чи ядерне, спочатку просто скиньте свою базу даних та відновіть її.

Якщо використовується POsgres -

DROP SCHEMA public CASCADE;
CREATE SCHEMA PUBLIC;

Тоді просто переробіть свої міграції

./manage.py migrate

Це найосновніше рішення, яке зазвичай прояснить ситуацію. Не просто переробляйте міграції, поки не стане абсолютно необхідним.


4
"що-небудь дивне або ядерне", а потім "спочатку просто скиньте свою базу даних і відновіть її". Якщо скидання бази даних не вважається ядерним, я б не хотів бачити, що це таке.
tbm

0

Мені потрібно скинути базу даних, а потім запустити makemigrations і перенести знову, щоб це було вирішено з мого боку.


0

видаліть папку міграцій та db.sqlite3 та введіть cmd python manage.py makemigrations


1
Незважаючи на те, що це може вирішити проблему, чи можете ви надати деяку інформацію про те, чому це також вирішить?
bob0the0mighty

тому що ти вже створив базу даних sql зі структурою та деякими даними в ній, і коли ти робиш деякі зміни, які можуть торкнутися даних ур та змінити модель ур, це вказує на помилку
moncef banouri

0

django.db.migrations.exceptions.InconsistentMigrationHistory #On Creating Custom User Model

У мене була та сама проблема сьогодні, і жодне з наведених вище рішень не спрацювало, тоді я подумав стерти всі дані з моєї локальної бази даних PostgreSQL, використовуючи цю наступну команду

-- Drop everything from the PostgreSQL database.

DO $$
DECLARE
        q TEXT;
        r RECORD;
BEGIN
        -- triggers
        FOR r IN (SELECT pns.nspname, pc.relname, pt.tgname
                FROM pg_catalog.pg_trigger pt, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace AND pc.oid=pt.tgrelid
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pt.tgisinternal=false
            ) LOOP
                EXECUTE format('DROP TRIGGER %I ON %I.%I;',
                    r.tgname, r.nspname, r.relname);
        END LOOP;
        -- constraints #1: foreign key
        FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
                FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pcon.contype='f'
            ) LOOP
                EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
                    r.nspname, r.relname, r.conname);
        END LOOP;
        -- constraints #2: the rest
        FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
                FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pcon.contype<>'f'
            ) LOOP
                EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
                    r.nspname, r.relname, r.conname);
        END LOOP;
        -- indicēs
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind='i'
            ) LOOP
                EXECUTE format('DROP INDEX %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- normal and materialised views
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind IN ('v', 'm')
            ) LOOP
                EXECUTE format('DROP VIEW %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- tables
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind='r'
            ) LOOP
                EXECUTE format('DROP TABLE %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- sequences
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind='S'
            ) LOOP
                EXECUTE format('DROP SEQUENCE %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- extensions (only if necessary; keep them normally)
        FOR r IN (SELECT pns.nspname, pe.extname
                FROM pg_catalog.pg_extension pe, pg_catalog.pg_namespace pns
                WHERE pns.oid=pe.extnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
            ) LOOP
                EXECUTE format('DROP EXTENSION %I;', r.extname);
        END LOOP;
        -- aggregate functions first (because they depend on other functions)
        FOR r IN (SELECT pns.nspname, pp.proname, pp.oid
                FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns, pg_catalog.pg_aggregate pagg
                WHERE pns.oid=pp.pronamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pagg.aggfnoid=pp.oid
            ) LOOP
                EXECUTE format('DROP AGGREGATE %I.%I(%s);',
                    r.nspname, r.proname,
                    pg_get_function_identity_arguments(r.oid));
        END LOOP;
        -- routines (functions, aggregate functions, procedures, window functions)
        IF EXISTS (SELECT * FROM pg_catalog.pg_attribute
                WHERE attrelid='pg_catalog.pg_proc'::regclass
                    AND attname='prokind' -- PostgreSQL 11+
            ) THEN
                q := 'CASE pp.prokind
                        WHEN ''p'' THEN ''PROCEDURE''
                        WHEN ''a'' THEN ''AGGREGATE''
                        ELSE ''FUNCTION''
                    END';
        ELSIF EXISTS (SELECT * FROM pg_catalog.pg_attribute
                WHERE attrelid='pg_catalog.pg_proc'::regclass
                    AND attname='proisagg' -- PostgreSQL ≤10
            ) THEN
                q := 'CASE pp.proisagg
                        WHEN true THEN ''AGGREGATE''
                        ELSE ''FUNCTION''
                    END';
        ELSE
                q := '''FUNCTION''';
        END IF;
        FOR r IN EXECUTE 'SELECT pns.nspname, pp.proname, pp.oid, ' || q || ' AS pt
                FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns
                WHERE pns.oid=pp.pronamespace
                    AND pns.nspname NOT IN (''information_schema'', ''pg_catalog'', ''pg_toast'')
            ' LOOP
                EXECUTE format('DROP %s %I.%I(%s);', r.pt,
                    r.nspname, r.proname,
                    pg_get_function_identity_arguments(r.oid));
        END LOOP;
        -- nōn-default schemata we own; assume to be run by a not-superuser
        FOR r IN (SELECT pns.nspname
                FROM pg_catalog.pg_namespace pns, pg_catalog.pg_roles pr
                WHERE pr.oid=pns.nspowner
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast', 'public')
                    AND pr.rolname=current_user
            ) LOOP
                EXECUTE format('DROP SCHEMA %I;', r.nspname);
        END LOOP;
        -- voilà
        RAISE NOTICE 'Database cleared!';
END; $$;

Після цього ви можете запустити команду django для міграції

python manage.py makemigrations
python manage.py migrate

І абсолютно це спрацює. Дякую.


0

Прокоментуйте django.contrib.admin із встановлених програм, а також шлях коментарів ('admin /', admin.site.urls), потім повторіть makemigrations, а потім перенесіть. Це вирішить вашу проблему. Для отримання додаткової інформації перейдіть сюди


1
Деякі поради: намагайтеся не дублювати відповіді, які вже існують. Здається, вже вибране рішення. Якщо ваша відповідь інша, будь ласка, детальніше поясніть, чому, і надайте більше деталей, якщо можете. Наприклад, яка логіка для коментарів до django.contrib.admin (також, ви маєте на увазі коментар?). Навіщо повторювати міграцію?
Jairus Martin
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.