I created a migration file using python3 manage.py makemigrations my_app. However I ran that command by mistake. Is it safe just to delete the newly created non-processed migration file? Or is there something else that needs to be done?
Until you run migrate there's no record of the migration other than the existence of the file in the migrations directory. So yes, it's perfectly safe to delete it.
If you have not run migrations, its cool. Only take care that it does not create any dependency issues. For example if running makemigrations created 5 migration files in 5 different folders, Be sure to delete each one of them.
But if the migration was run and somehow could not be completed, then you should revert back the changes also before deleting the migration files.
Be careful with it and see django_migrations table to be extra sure.
Related
I have deleted migration folder because I have an issue which can't to solve. After that I try to migrate, but it wrotes me "No migrations to apply".
So, I don't understand why it wrote me this message, when I don't migrate these files.
Command python manage.py migrate seeks the migration files and then try to rebuild database according to that files. If you have deleted those files there is nothing to read/compare.
If you have deleted those files you might need to drop database and create new one unless you try makemigrations. But probably it will raise some errors if you made some important changes in model structures.
Run this command
python manage.py showmigrations
This migration looks like
[X] 0001_migration_filename.py
[X] which means migration is not deleted. so you need to delete migration from the database as well. if you are using sqllite3(by default database) then delete the .sql file or if you are using PostgreSQL or any other database then delete the migration file from the django_migration database.
So I've created a new model in Django, then executed both python manage.py makemigrations and python manage.py migrate in the right order. But then for some reason I accidentally dropped the table(relation) in PgAdmin (I know it sounds silly). So I tried deleting all the files in migrations folder but the init.py file. Then I ran the two commands above again, but could see no table in the PgAdmin. What should I do, aside from creating a table myself in PgAdmin?
Thanks in advance.
It won't work, because entry for all the migrations are already stored inside a table named django_migrations. So even if you run makemigrations after deleting all the migration files, it won't create a new one. So here is three ways you can fix it.
One: Drop DB(if data is not important)
Drop database and create a new one. Run makemigrations and migrate command.
Two: Create that table manually
If you already deleted all the migration files, you better restore them. You can use git for this: git checkout /path/to/migration/folder. Then you can manually create the table.
Three: Delete entries from django_migrations
I assumed you have deleted all the migration files. So this part covers the whole project. But #DenizKaplan has explained better way to do this.
If you are not using git, or no way to restore these files, then you can follow these steps:
Backup your database
Delete all entries from djang_migrations table
Run ./manage.py makemigrations to generate migration file
Run ./manage.py migrate <your lost app> to migrate your app(which you have lost in DB).
Run ./manage.py migrate --fake to fake the rest of apps.
There are some steps you need to check. If you have an empty output after makemigrations operations, you may need to check for django_migrations table to remove rows related to apps that you have working with. If this won't help at first place, you need check INSTALLED_APPS, maybe you may accidently delete apps. If all these not work, please give some detailed information about the error.
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?
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.
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 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.
More to read at: https://docs.djangoproject.com/en/2.2/topics/migrations/#migration-squashing
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.
when you import from third app:
there are 2 step uninstall it
there are use the 'django_celery_beat' app for example.
step1: clean table
python .\manage.py migrate django_celery_beat zero
step2: remove app from INSTALLED_APPS
there are done!!!
this is django document on this.
How to Reset Migrations
if you are using linux/unix os then you can fire this command. delete all migration directory.
find . -path "/migrations/.py" -not -name "init.py" -delete
find . -path "/migrations/.pyc" -delete
I have a Postgres database full of data. And I made several changes to my Django app models.
mange.py makemigrations worked fine and created the migration files. But manage.py migrate execute only one file. And when I launch it again it doesn’t execute the rest as if they are already applied.
I deleted the migration files that were not applied and did another makemigration but it says no changes detected.
Any ideas how to reflect the models changes on the database without losing the data ?
Thanks
Django keeps track of which migrations it has applied already, so when you run the migrate command it will execute only the migrations that Django thinks that are missing.
I deleted the migration files that were not applied and did another makemigration but it says no changes detected.
This was a bad idea, it will make your migrations inconsistent.
If you want to go back in time, instead of deleting migrations, the proper way to do this is by reverting migrations. You can use the same migrate command and specify to which migration point you want your database model to be.
Check this answer for further information about reverting migrations; django revert last migration
Actually we are group of 3 people working on the same project, and each one individually make changes in django database. After running migrations in individual machine, it creates migration file for each migration. When someone pushes updated code in remote git repository, it creates conflict with others' migrations of same name.
Because of this reason, I lost my whole data once. Kindly give suggestions what should I do with this migration thing?
here's what i do: whenever I want to fetch from remote i check if a duplicate migration will be fetched. (we have a script that checks for all migration directories if there are filenames which have the same starting number.) if that is the case, I 'merge' the migrations, usually like this:
Find the last migration before the duplicate, let's say it's migration 000X
Make sure you are on your local source version, before the duplicate is added.
migrate back to after migration n:
python manage migrate app 000X
pull the new version including the duplicates.
remove your duplicate migrations
run schemamigration
python manage schemamigration --auto
Now you should get a new migration adding your model changes on top of the changes that were made in the migration you pulled.