I am a beginner using Django. I have recently been working on a website that has a few different pages. I reference a couple of views from other apps in urls.py. One app I used to take inputs and make some calculations, so it had some forms defined. It was all working fine and I was able to import the views fine, but I changed one of my form field names. This caused some problems because I was storing these values in a database. That made sense to me because I had already saved some data with the previous naming convention and now I had changed it. So, I figured that deleting my database and migrations would allow me to start over and start a new database with my updated fields. I messed up though because I read that I should not have deleted my init.py file in my migrations folder.
I have tried re-doing my migrations with makemigrations and migrate but I keep getting an error saying that no changes are made and no new migrations show up in my folder. Also, now when I look in my urls.py file, the imported views and apps are showing up with a red underline and says "import package".
I have also tried reverting my code back and was able to get the migration files back, but the same error was shown in my urls.py file.
I have tried just about everything I could find online, but am now thinking that I may just have to recreate these apps.
Any help is appreciated!
First of all, to rename a form field, just change it in the models and then make and apply migrations. Django should detect the renaming of an existing field and create migrations.AlterField(...) statements (you can inspect the migration files that were created, and freely delete them if they are not yet applied/migrated).
First, please check if adding the empty file called __init__.py to the migration folder solves the problem. This is a python requirement, to let the interpreter know that the folder contains a python module.
Also if you have downloaded the project from somewhere, you need to have the existing migrations. Deleting them and recreating them yourself will likely fail.
After that just try running
python manage.py makemigrations
python manage.py migrate
If there are still no changes, check if there are migrations applied to your database by looking at the django_migrations table or by running this command:
python manage.py showmigrations
If this did not help, try to start with a clean project:
Backup all your code changes and revert to the starting point, the __init__.py file should be back and you should also delete the database (db.sqlite3)
run the migrate command
add all your code changes
check if your code changes have new migration files, they could cause problems. If you have not created or modified them manually, you can delete and let Django recreate them
Related
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've deployed my Django application for a while now, but all this time I've kept migrations out of souce control. What I did was run makemigrations and migrate twice-- once in development, and once in production. So now how can I seamlessly put my migrations into source control? Theoretically the migrations should be the same (given my models.py files haven't changed), but how would I go about matching my migrations up without accidentally overriding something?
I'm not sure if I understand the problem...
Django keeps track of which migrations have been applied using the database. But it uses the names, not the contents. So as long as you're not changing the contents of migrations that have already been applied, you should be good.
I just followed this procedure:
makemigrations (success)
migrate (success)
Copy the app on another server (with the migration files)
Create a new empty database on that server
migrate (success, it creates the correct schema)
Fill the new database with data
Just to test: migrate ....
At this point Django says I have "changes that are not yet reflected in a migration, and so won't be applied. Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them"
But when I run makemigrations, it creates a new one that wants to "Remove field" every foreign key and "Delete model" all of my models. If I run it it empties my database. My models.py are intact.
What is happening ??
I had the same problem in my project. Running forward I can say that django removes models that has no import (making the Delete model migration). The documentation says that you should import your model in the myApp/models/__init__.py file (see https://docs.djangoproject.com/en/1.11/topics/db/models/#organizing-models-in-a-package).
In my case I imported the model somewhere to make manipulations but model had been removing elsewhere.
I had made a useless import in an admin.py file that has solved my situation (I didn't try to follow the documentation and import it in the __init__.py but sure it should help).
I had not realized yet why does it work that way (hope that someone could note this moment) and also hope this solution will help you.
I've just had the same errors, but I hit the makemigrations building a migration full of Remove Field and Delete Model commands before I tried the migrate command.
In my case, the solution was related this being an old project I was resurrecting, and it had a number of Model.Meta.app_name values set, as well as entries in apps.py for each project. These were now in conflict with the way settings was interpreting the project, and even though my models were imported into views and admin, they weren't being seen by the migration code. Deleting these app_name tags on the models, and modifying the AppConfig name in apps.py solved this, so that the running makemigrations again caused the expected changes (alter field, etc), and all was fine.
I didn't find any other questions or answers that quite matched this one and my experience, so I hope if anyone else looks for this, they'll find it here like I did ;-)
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.
What is the procedure for completely uninstalling a Django app, complete with database removal?
Django < 1.7 has a handy management command that will give you the necessary SQL to drop all the tables for an app. See the sqlclear docs for more information. Basically, running ./manage.py sqlclear my_app_name gets you get the SQL statements that should be executed to get rid of all traces of the app in your DB. You still need to copy and paste (or pipe) those statements into your SQL client. For Django 1.7 and up, use ./manage.py migrate my_app_name zero (see the migrate docs), which runs the database cleaning automatically.
To remove the app from your project, all you need to do is remove it from INSTALLED_APPS in your project's settings.py. Django will no longer load the app.
If you no longer want the app's files hanging around, delete the app directory from your project directory or other location on your PYTHONPATH where it resides.
(optional) If the app stored media files, cache files, or other temporary files somewhere, you may want to delete those as well. Also be wary of lingering session data that might be leftover from the app.
(optional) I would also remove any stale content types.
Like so.
from django.contrib.contenttypes.models import ContentType
for c in ContentType.objects.all():
if not c.model_class():
print "deleting %s"%c # print(f"deleting {c}") # for Python 3.6+
c.delete()
In my context the projects exists several times: I have a development system, some team mates have a development system, there is a staging system for the customer and a production system. This means I don't want to execute sql commands by hand. I want it to be automated.
Goal: Remove the app and all database tables.
Step 1: empty the app, but leave it installed
remove all files from the app, except the folder "migrations"
Execute this command:
python manage.py makemigrations -n drop_all_tables my_app_to_remove
The directory looks now like this:
my_app_to_remove/
my_app_to_remove/__init__.py
my_app_to_remove/migrations
my_app_to_remove/migrations/0001_initial.py
my_app_to_remove/migrations/....
my_app_to_remove/migrations/0030_drop_all_tables.py
my_app_to_remove/migrations/__init__.py
Leave my_app_to_remove in the file "settings.py".
Step 2: Deploy the changes
Update all projects. Tell the team mates to update their project and to run the migrations.
Step 3: remove "my_app_to_remove" from settings.py
Now remove "my_app_to_remove" from settings.py and deploy again.
comment out on settings.py in INSTALLED_APPS unnecessary app's line
delete all folder __pycache__ and migrate at your project
delete unnecessary model in models.py
delete all import link in views.py, admin.py end etc.
delete all link's in urls.py on your unnecessary app's
in database delete unnecessary tables wich associated with the app (I do it with help program "Valentina Studio")
delete app's folder
in command line do it: python manage.py migrate and python manage.py syncdb
django app is a "set" of *.py files and a directory with a django-app-name. So you can simply delete the whole folder with all *.py files
To "remove" tables from DB you should use DELETE FROM <app-name_table-names>
Furthermore, you have to delete lines witgh app-name from setting.py in a root directory
As a first step, prevent any usage of the app models and deploy. This is essential for rolling deployment. Check notes below.
Then you have two options.
Option 1
(Manual) Run python manage.py migrate <app_name> zero. This will revert all the migrations for the app and clean the django_migrations table
Remove app (code, INSTALLED_APPS, urls.py, etc.)
Deploy (python manage.py migrate)
Option 2
Remove all models in the app
Deploy
Remove the app (code, INSTALLED_APPS, urls.py, etc.)
Deploy
(Manual) Clean django_migrations table
This answer is thinking in an automated rolling deployment context (e.g. Heroku).
Manual means it normally cannot be done in automated deployment. Deploy basically refers to python manage.py migrate which is normally done in automated deployment.
Notes
Make sure to remove code importing this app from other apps. Also any references in settings.py (but keep it in INSTALLED_APPS so we can run migrations), urls.py, etc.
migrate <app_name> zero will revert all migrations depending on those migrations. So be careful if your other apps migrations depend on these migrations.
Also be aware of cascade delete if you have not just schema migrations but also data migrations.
Signal receivers receiving signals defined in other apps might be an issue in rolling deployment.
References
https://docs.djangoproject.com/en/stable/ref/django-admin/#migrate
Safely Remove a Django app by Jordan Haines
To completely remove a Django app (with models), follow the steps below. Let’s pretend we’re removing an app called note_app:
Search through your other apps for any note_app imports. The easiest way to do this is a project-wide search for “from note_app”. You may want to exclude the note_app directory from your search.
Comment out all models in note_app.models. You may need to also remove entries from note_app.admin file if you registered your note_app models with Django admin.
Look for and resolve errors when trying to run your Django app. P.S. You may have missed some model imports in step 1.
Note that depending on how you define ForeignKey, OneToOne and ManyToMany fields, you may have missed some keys to your note_app models in step 1. It’s important that any fields that point to note_app models from models in other apps need to be deleted before you continue. Take a minute to make sure none of these fields were missed; if they were, then delete those fields that remain and create migrations that will remove the fields from your database.
Run makemigrations. This should create a note_app migration that deletes all of the models you just commended out. This migration should also remove fields referring to note_app models from models in other apps.
Run your migrations. You must run your migrations in all environments (including production) BEFORE you delete the app directory. The migrations that remove your app’s models from the database will be — surprise — in your note_app directory. If you delete the app directory prematurely, you will delete these migrations before they have a chance to clean up your database.
You may get a notice that the content types for your deleted models are stale. When asked whether or not you want to delete these content types, reply “yes”
Git Tip: Commit your migrations, take note of the commit, and then create a separate commit that deletes the note_app directory. When you are ready to apply your changes in a staging or production environment, checkout the commit you noted, run the migration, and then checkout the latest commit to delete the app directory. Your first commit should still have note_app in INSTALLED_APPS.
Delete the directory that contains the note_app.
Remove note_app from your INSTALLED_APPS setting.
And that’s really about it…super easy :)