I have a newly created Django project/app and I created the initial migrations in SQLLite just to make sure I could run the app and also login to the Admin dashboard. All that is fine.
I then created a new MySQL database and I replaced the SQLLite connection with the MySQL connection. I can run the app wthout issues, and it properly connects to the MySQL db.
Now, I want to run all the migrations on the new DB to create all of the authorization tables, and then CreateSuperuser to create the admin user in this new MySQL database.
Are there some guidelines on how to do this? I have read where I need to delete all files in the Migrations folders under .venv\Lib\site-packages\django\contrib folder such as admin, auth, etc. I just want to make sure I am not deleting anything that shouldn’t be removed. I tried this previously and must have deleted a file that should not have been deleted, because the app stopped working. I just deleted the whole project and started over at that point, since I hadn’t gotten too far into it.
If there is any guidance on this, I would appreciate it.
Thanks!
You shouldn’t need to do anything special. Once you’ve changed the DATABASES setting to point to your new database, then just run migrate. Do not delete any of your migrations - it’s not necessary. (In the general case, you should never delete any migration files - especially after they’ve been applied.)
I tried that and it showed that no migrations were needed.
But then I realized I hadn’t switched the data source back to the MySQL database, so I did that and tried to migrate again and got this error.
MySQLdb.OperationalError: (1050, “Table ‘auth_permission’ already exists”)
However, I can confirm that the database in question has no tables, so I’m not sure where it is looking to determine which tables already exist.
There are two other Django apps on the local MySQL server, so I’m wondering if it is somehow getting confused with one of those??
It is looking at the database identified in the DATABASES setting.
I would suspect that the database you are looking at is not the database configured for your project.
As long as those other two projects are using a different database than the one you’re trying to use, there is no conflict.
Okay, all set. I wasn’t seeing the tables created in the database through JetBrains DataGrip, and I had done, what I thought was unsuccessful migrations before this. I didn’t realize that I had to do refresh in DataGrip to see the updates, but now I am seeing them.
Thanks for you help!
Okay, I have a follow-up to this. Apparently, there are still some migration issues.
I created a new model but the migrate command failed with the following error.
django.db.utils.OperationalError: (1050, “Table ‘django_admin_log’ already exists”)
I can see that the django_admin_log table is in fact created in the database. The problem is that when I get this error, the migration stops and it doesn’t create the table for the new model that I created.
Is there any way to clear the status of the previous migrations so that I can create the new model?
I tried python manage.py migrate --fake auth in order to clear the status of all authorization tables and that helped a bit as the initial error concerned the auth_user table and I no longer see that error message. Is there another fake command that works with the django_admin tables?
Thanks!
There’s only one “fake” parameter, and what follows it in the command line is the name of the app to which it is applied. So yes, you can use that with admin as the parameter instead of auth.
But I’d be more concerned about getting these errors at all.
Are you making any manual changes to your migration files? Did you manually create or alter any tables within your database? Delete contents of any system-related tables?
If any of these is true, then this is another case where I’d suggest deleting the database and recreating it. Then run migrate to ensure everything is created as it’s supposed to be. (Running with fake is a work-around, and can create other issues on its own. It’s not a “guarantee fix” for anything.)
The key lesson to learn here is to not second-guess what migrate is doing. If you’re going to use migrations to manage the database, then let it do so. You’re best served by not interfering with its normal operations.
If you’re going to manually manage your database, that’s ok too - there are cases where it may be appropriate to do so. But when you do run into a situation like that, then do not try to add migrate into the mix.
Okay, thanks Ken, and I agree that I should let the migration process take its course. That has always worked for me with other projects, but for some reason, this project got a bit messed up, I think when I switched the DB to MySQL.
I have basically two options at this point. I can trash the whole project and start over. I’m only about 4 hours into it, so not the worse thing in the world. That might be the way to go to make sure I have a clean start.
The other option as you said, is that I can delete and recreate the database. At this point, it only has the initial Django admin tables, so not a big deal. My question about this though, is how will the migrate process know to create all of the tables? Does it actually check the schema of the database, or does it just view the log files within Django to determine if the migrations were done? I’d hate to delete and recreate the database, only to continue to have problems with the migration process.
Your thoughts on this?
The migrate process maintains a migrations table in the database. That’s what it uses to determine which migrations have been applied. See the docs at Migrations | Django documentation | Django for more details.
The makemigrations command will create migration files, and you can create migration files manually. The migrate command will only read them - it doesn’t make any changes to your system. The only changes that migrate will make will be to the database.
Changing databases isn’t going to cause problems, unless you’ve done something to interfere with the processes such as deleting migrations files or any other similar mistake.
Two keys to keep migrations happy:
- Don’t alter (edit or delete) migration files, especially after they’ve been applied
- Don’t manually alter any database table that is being managed by migrations.
If you strictly follow those two rules, you’ll generally find that everything works quite smoothly.