Как удалить файлы миграции django
Я выполнил миграцию, которая добавила новую таблицу, и хочу отменить ее и удалить миграцию, не создавая новую миграцию.
Как это сделать? Есть ли команда для отмены последней миграции, а затем я могу просто удалить файл миграции?
Например, если ваши последние две миграции:
- 0010_previous_migration
- 0011_migration_to_revert
Тогда вы бы сделали:
На самом деле вам не нужно использовать полное имя миграции, достаточно номера, т.е.
Затем вы можете удалить миграцию 0011_migration_to_revert .
Если вы используете Django 1.8+, вы можете показать имена всех миграций с помощью
Чтобы отменить все миграции для приложения, вы можете запустить:
Разве пользователи обычно не хотят также удалить файл миграции? Я часто ловлю себя на том, что выполняю миграцию, а затем переосмысливаю ее и заново создаю, прежде чем совершать что-то чистое, поэтому мне обычно нужно помнить «rm path/to/0011_migration_to_revert.py».
Это только «демигрирует». Если вы больше не хотите выполнять эту миграцию, вам также необходимо удалить файл миграции.
Пока вы используете свое фактическое имя миграции, а не '0010_previous_migration' , я не знаю, почему вы увидите такое поведение.
Используя django 2.1, у меня это работает: /manage.py migrate my_app 0010 , только 0010 , а не полное имя файла. После этого вручную удалите локальные файлы appname/migrations/0011+, затем вручную удалите строки из таблицы django_migrations db для 0011+.
Ответ Аласдера охватывает основы
- Определите нужные миграции с помощью ./manage.py showmigrations
- migrate с использованием имени приложения и имени миграции
Но следует отметить, что не все миграции можно отменить. Это происходит, если у Django нет правила для реверсирования. Для большинства изменений, которые вы автоматически внесли при переносе ./manage.py makemigrations , будет возможно отменить. Тем не менее, пользовательские скрипты должны иметь как прямую, так и обратную запись, как описано в примере здесь:
Как сделать безоперационный разворот
Если у вас была операция RunPython , то, возможно, вы просто хотите отменить миграцию без написания логически строгого сценария отмены. Следующий быстрый взлом примера из документации (ссылка выше) позволяет это сделать, оставляя базу данных в том же состоянии, в котором она была после применения миграции, даже после ее отмены.
Это работает для Django 1.8, 1.9
Не удаляйте файл миграции до реверсии. Я сделал эту ошибку, и без файла миграции база данных не знала, что нужно удалить.
Если вы хотите отменить все миграции, используйте zero в качестве имени миграции:
Удалите файл миграции. Как только желаемая миграция будет в ваших моделях.
Вот мое решение, поскольку приведенное выше решение на самом деле не охватывает вариант использования, когда вы используете RunPython .
Вы можете получить доступ к таблице через ORM с помощью
Таким образом, вы можете запросить таблицы и удалить те записи, которые важны для вас. Таким образом, вы можете изменить детали. При миграции RynPython вам также необходимо позаботиться о данных, которые были добавлены/изменены/удалены. В приведенном выше примере показано только то, как вы получаете доступ к таблице через Djang ORM.
Чтобы отменить миграцию:
MIGRATION_NUMBER_PREFIX – это префикс номера миграции, к которой вы хотите вернуться, например 0001 , чтобы перейти к миграции 0001_initial.py . то вы можете удалить эту миграцию.
Вы можете использовать zero в качестве номера миграции, чтобы отменить все миграции приложения.
Другая вещь, которую вы можете сделать, это удалить таблицу, созданную вручную.
Наряду с этим вам придется удалить этот конкретный файл миграции. Кроме того, вам придется удалить ту конкретную запись в таблице django-migrations (вероятно, последнюю в вашем случае), которая связана с этой конкретной миграцией.
Я сделал это в 1.9.1 (чтобы удалить последнюю или последнюю созданную миграцию):
пример: rm myapp/migrations/0011*
вошел в базу данных и запустил этот SQL (в этом примере postgres)
delete from django_migrations where name like '0011%';
Затем я смог создать новые миграции, которые начинались с номера миграции, который я только что удалил (в данном случае 11).
+1 Хотя это сработает, вам нужно сохранить этот способ в крайнем случае. Также вы должны не забыть отредактировать/удалить столбец/таблицы, в которых возникла проблемная миграция.
Хороший момент - я использовал это, когда создавал миграцию, но еще не запускал "./manage.py migrate"
Вы можете вернуться, перейдя на предыдущую миграцию.
Например, используйте следующую команду:
Затем удалите файл last_migration .
Если вы столкнулись с проблемой при откате назад миграции и каким-то образом напортачили, вы можете выполнить миграцию fake .
Для django версии south_migrationhistory , вам нужно удалить эту запись.
Теперь вы сможете легко отменить миграцию.
PS: я застрял на много времени, и мне помогло выполнение поддельной миграции, а затем откат назад.
Этот ответ предназначен для подобных случаев, если лучший ответ Alasdair не помогает. (Например, если нежелательная миграция создается вскоре снова с каждой новой миграцией или если она находится в более крупной миграции, которую нельзя отменить, или таблица была удалена вручную.)
. удалить миграцию, не создавая новую миграцию?
TL;DR: вы можете удалить несколько последних измененных (неверных) миграций и создать новую после исправления моделей. Вы также можете использовать другие методы, чтобы настроить не создавать таблицу с помощью команды migrate. Последняя миграция должна быть создана так, чтобы она соответствовала текущим моделям.
Случаи, почему никто не хочет создавать таблицу для Модели, которая должна существовать:
A) Такая таблица не должна существовать ни в одной базе данных, ни на одной машине и ни при каких условиях.
- Когда: это базовая модель, созданная только для наследования модели от другой модели.
- Решение. Установите class Meta: abstract = True
Б) Таблица создается редко, чем-то другим или особым образом вручную.
- Решение. Используйте class Meta: managed = False
Миграция создается, но никогда не используется, только в тестах. Файл миграции важен, иначе тесты базы данных не могут быть запущены, начиная с воспроизводимого начального состояния.
C) Таблица используется только на какой-то машине (например, в разработке).
- Решение. Переместите модель в новое приложение, которое добавляется в INSTALLED_APPS только при особых условиях, или используйте условное выражение class Meta: managed = some_switch .
D) В проекте используется несколько баз данных в settings.DATABASES
- Решение. Напишите Маршрутизатор базы данных с методом allow_migrate , чтобы различать базы данных, где следует создавать таблицу, а где нет.
Миграция создается во всех случаях A), B), C), D) с Django 1.9+ (и только в случаях B, C, D с Django 1.8), но применяется к базе данных только в соответствующих случаях или никогда, если требуется так. Миграции были необходимы для запуска тестов, начиная с Django 1.8. Полное релевантное текущее состояние записывается миграциями даже для моделей с управляемым = False в Django 1.9+, чтобы можно было создать ForeignKey между управляемыми/неуправляемыми моделями или сделать модель управляемой = True позже. (Этот вопрос был написан во время Django 1.8. Все здесь должно быть действительным для версий от 1.8 до текущей версии 2.2.)
Если последнюю миграцию нелегко отменить, можно осторожно (после резервного копирования базы данных) выполнить поддельный возврат ./manage.py migrate --fake my_app 0010_previous_migration , удалите таблицу вручную.
При необходимости создайте фиксированную миграцию из фиксированной модели и примените ее без изменения структуры базы данных ./manage.py migrate --fake my_app 0011_fixed_migration .
Есть хорошая библиотека для использования под названием djagno-nomad, хотя она и не имеет прямого отношения к заданному вопросу, подумала о том, чтобы поделиться этим,
Сценарий: большую часть времени при переключении на проект мы чувствуем, что он должен отменить наши изменения, которые мы сделали в этой текущей ветке, именно это и делает эта библиотека, проверка ниже
В процессе разработки проекта на Django мы можем столкнуться с неприятной ситуацией, когда некоторые пакеты и модули были удалены и, соответственно, модели из этих пакетов больше не использовались. Но в то же время сквош миграций приложений не позволяет удалить эти пакеты, так как миграции имеют много циклических зависимостей. В результате удаление ненужных пакетов становится довольно сложной задачей. Так как разрешение таких зависимостей становится нетривиальной задачей. Для меня таким неприятным пакетом был Django CKEditor, который присутствовал почти везде. В итоге этот пакет из-за миграций довольно долго оставался в списке requirements.txt, хотя по факту на сайте вообще не использовался.
Чтобы избавиться от таких зависимостей миграций, нужно удалить все миграции, при этом не удаляя контент, который был создан этими миграциями. А затем создать новую начальную миграцию и применить ее к базе данных также без внесения новых изменений в структуру базы данных.
Вернуть все миграции в нулевое состояние с параметром fake. Это означает, что информация о миграции будет удалена, но содержимое не изменится.
Удалить файлы миграции из репозитория
Создайте новый файл миграции
Запустите новую миграцию с параметром fake, чтобы добавить информацию о миграции в базу данных, но не изменять структуру базы данных.
Внимательно применяйте этот подход к настройке миграций и лучше создайте новую миграцию на тестовом сервере, чтобы убедиться, что вы все делаете правильно и база данных не сломается.
При этом на тестовом сервере можно создать новую миграцию и добавить ее в репозиторий git.
Затем на рабочем сервере вам нужно будет сделать следующее.
Рекомендуем хостинг TIMEWEB
Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.
При работе с базами данных нам часто приходится перезагружать базу данных, потому что мы заполняем ее бесполезными данными. Иногда мы даже создаем базу данных на основе схемы базы данных, подверженной ошибкам. Иногда мы даже меняем бизнес-логику, которая корректирует весь дизайн базы данных. Эти ситуации довольно распространены в области компьютерных наук, и для их обработки созданы несколько хороших инструментов и команд.
- Сбросить всю базу данных
- Вернуть приложение Django к некоторым старым миграциям.
Сбросить всю базу данных в Django
- Если мы используем базу данных SQLite по умолчанию в Django, мы можем удалить файл базы данных db.sqlite3 , а затем удалить все папки migrations во всех приложениях. После удаления папок migrations мы можем переделать миграции и перенести их с помощью двух команд; а именно python manage.py makemigrations и python manage.py migrate .
- Если мы используем какую-либо другую реляционную базу данных, такую как PostgreSQL или MySQL, мы можем либо удалить все таблицы с помощью инструмента управления базой данных, такого как pgAdmin , DBeaver и т. Д., Либо вручную, используя командную строку. Или мы можем создать совершенно новую базу данных, а затем подключить ее к нашему проекту Django. Обратите внимание, что в обоих случаях нужно сначала удалить все папки migrations , а затем заново выполнить миграции и, наконец, перенести их.
- Другой вариант - использовать команду Django manage.py , чтобы очистить для нас всю базу данных. Команда - python manage.py flush . Опять же, после использования этой команды мы должны удалить все папки migrations , а затем выполнить новые миграции.
Вернуть приложение Django к его старым миграциям
Если нам не нужно сбрасывать всю базу данных, а откатывать миграции для определенного приложения Django, у нас есть два варианта для этого. Во-первых, мы можем отменить текущие миграции приложения Django на некоторые старые миграции. Во-вторых, мы можем сбросить все миграции для приложения Django.
Если нам нужно вернуться с какой-то последней миграции, скажем, 0014, на более старую миграцию, скажем, 0008, мы можем использовать следующие команды.
И, если нам нужно сбросить все миграции для приложения Django, мы можем использовать следующую команду.
Обратите внимание, что иногда миграции могут быть необратимыми. Как правило, это состояние возникает, когда в модели Django были внесены некоторые существенные изменения. Когда мы попытаемся вернуться к такой миграции, Django выдаст IrreversibleError .
Сопутствующая статья - Django Migration
report this ad
У меня есть приложение Django с множеством устаревших миграций. Я хотел бы удалить старые миграции и начать все заново.
Приложение имеет 14 различных папок "миграции".
Вот как выглядят некоторые из них:
Безопасно ли удалять все содержимое из каждой из этих папок? Или мне нужно обязательно удалить некоторые из файлов - и если да, то какие файлы?
3 ответа
Вам следует никогда просто удалять миграции, прежде чем их отменять, или это будет кошмар, когда вы захотите применить новые миграции.
Чтобы отменить миграцию, вы должны сделать следующее:
Используйте python manage.py migrate your_app_name XXXX на случай, если вы хотите отменить миграцию после миграции XXXX. В противном случае используйте python manage.py migrate your_app_name zero , чтобы полностью отменить все миграции.
Удалите файлы .pyc из / migrations / __ pycache __ /, которые вы не применили.
Удалите файлы .py из миграций / которые вы не применили.
Теперь вы можете создавать новые миграции без головной боли.
Если вам нужно объединить все миграции в одну, выполните описанные выше шаги, удалив все миграции, а затем запустите python manage.py makemigrations your_app_name , чтобы создать один файл миграции. После этого просто запустите python manage.py migrate your_app_name и все готово.
Это зависит от. Если у вас есть производственная база данных (или любая база данных, которую вы не можете просто удалить и воссоздать), то ответ - нет, вы не можете безопасно удалить миграции.
Если у вас нет постоянных баз данных, тогда да, вы можете удалить все миграции, запустить python manage.py makemigrations --initial , и он создаст новые миграции на основе ваших текущих моделей.
Кроме того, вы должны проверить, являются ли какие-либо миграции пользовательскими миграциями данных, написанными вручную. Если таковые имеются, вы можете сохранить их.
Файлы .pyc, как правило, безопасны для удаления при условии, что соответствующие файлы .py все еще там.
I've got a Django app with a lot of out-of-date migrations. I'd like to remove the old migrations and start fresh.
The app has 14 different "migrations" folders.
Here is what a few of them look like:
Is it safe to remove all the contents from each of these folders? Or, do I have to make sure to only remove some of the files -- and if so which files?
If you've not created some custom migrations for like loading data, then yes. It should be safe to remove all of the migrations in the migrations folder and run makemigratons command. You can always copy old migrations for backup unless you store them under version control like git. Then manual backup is not needed ofc.
5 Answers 5
You should never just delete migrations before unapplying them, or it will be a nightmare when you want to apply new migrations.
To unapply migrations you should do the following:
Use the python manage.py migrate your_app_name XXXX in case you want to unapply migrations after the XXXX migration. Otherwise use python manage.py migrate your_app_name zero to completely unapply all migrations.
Remove the .pyc files under /migrations/_pycache_/ that you have unapplied.
Remove the .py files under migrations/ that you have unapplied.
Now you can create new migrations without any headaches.
If what you're looking for is to squash all the migrations into one, do the steps above removing all migrations and then run python manage.py makemigrations your_app_name to create a single migration file. After that just run python manage.py migrate your_app_name and you're done.
I'm still something of a newbie at Django migrations. I don't want to unapply any migrations. All the created migrations have been applied on my local dev system, and everything is working correctly on dev. The production db is up-to-date with the dev db, so I don't need to apply the migrations to production. That's why I'm thinking it might be helpful to delete the old migration files prior to pushing to production. Does that make sense?
Django stores the newest migrations information in the database. Thus if you remove now all of the current migrations and create new one ( 0001_initial.py ), once you run manage.py migrate on production database you will get yourself into troubles. You can only remove migrations if you can drop the whole database and load the data manually from backup after running fresh migrations.
In that case it is not safe to remove migrations, since you have it in production and your database is probably populated with data. If you do it, all your data will be lost. Like the Beatles said, just let it be.
If you delete your migrations, there's no way for you to reproduce the current production setup. Image you break your local DB. There's no way to go back, or figure out what's running in production (short of jumping into the production database and analysing the schema manually). Migrations are there to help you reach the same DB state again.
That depends. If you have a production database (or any database you cannot simply drop and recreate), then the answer is no, you cannot safely remove migrations.
If you do not have any permanent databases, then yes, you can remove all migrations, run python manage.py makemigrations --initial and it will create fresh migrations based on your current models.
Also, you should check if any of the migrations are custom data migrations written by hand. If there are any, you might want to keep those.
The .pyc files are generally safe to remove, provided the related .py files are still there.
your first screenshot is not Django and looks like a JS project of some sort.
The migrations are applied in a sequence. If you remove migrations and then need to make changes, you will not be able to apply the new migrations to your production database. Don't delete anything.
- The json and js files are unrelated to the django migrations as well as __pycache__ folder. You can delete all off them.
- If you mean "previously applied and no longer needed as the project only needs the latest version of the migrations" you don't want to remove but squash them instead with squashmigrations which reduces the files you have to two, init file and the initial migration file, this way your project still works.
- If by remove you mean you no longer need them because you already changed the models so much that the previous migrations aren't even used other than being applied and unapplied without ever being used, doesn't matter, go to step 2 and do that instead of deleting the files manually. When you create migrations on your applications one by one, you also create migration dependency tree, well, django does. And it is really hard to keep track of after some point, if you try to delete everything thinking you can create new migration files with ease, trust me as someone who experienced otherwise, it does not work like that. It is way simpler to let django handle the migration squashing, it optimizes the migration meaning that it also deletes the unused ones in your final state.
Having marked one of the answers provided previously as being accepted, here is a summary of a few things I learned:
- Deleting Django migrations is generally a bad idea.
- Django keeps track of what's in your db through these migration files, as well as through a table it creates in your db, and if you delete any of this Django will start throwing errors on migrate that can be hard to fix.
I was getting some of those hard-to-fix errors. Here is what I did to fix it:
- Ran migrate on the production server.
- When I got an error, it would tell me how the db was out of sync with what Django expected. I corrected that manually by directly editing the db with an sql client.
- E.g. If it said a key existed that wasn't supposed to exist, I deleted the relevant index from the indicated table.
- Or if it said a table existed that wasn't supposed to exist, I backed up the table to a file, and deleted the table. Migrate then created the table, and then I repopulated it with data from the backup.
- In the case of many-to-many tables, once Django had re-created them, I deleted all the new Django-created tables, and restored them from a backup created on my local dev system, which had already had all the latest migrations run on it.
Eventually I was able to complete all migrations successfully.
I have a feeling I lucked out and the above won't work in all cases! I've learned a lot about Django and migrations and will be much more careful about this in the future.
Читайте также: