Long story short. I tried to add a custom user model to my existing project and realized too late that it wouldn’t work well as I already started my project. Then I deleted the migrations, all the customusermodel related codes and re ran makemigrations and migrate. Nothing wrong showed up at this point.
Then I started following a tutorial to create a profile model to link to the default User model and everything was fine until I wanted to create a new superuser and django showed this error:
django.db.utils.OperationalError: no such table: auth_user.
Then, I saw similar errors online and and followed one of the solutions which was to fake migrate the app (accounts for me) and then re run migrations. So I did that but then this error showed up when I try to run Python manage.py migrate:
django.db.utils.OperationalError: table "accounts_profile" already exists.
After this, I posted my error on stackoverflow (link : python - (Stuck!) Django operational error: table “accounts_profile” already exists - Stack Overflow) and one user suggested me to run this line of codes:
Python manage.py migrate auth zero --fake and then Python manage.py migrate auth. I did that but now I get the error :
django.db.utils.OperationalError: table "auth_permission" already exists
Today, I have ventured into far too much unknown territory of django and now I am in a mess which I have no idea how to solve and so I need help. I would not like to delete my database as it contains existing data and the website is also live. What do you guys recommend I should do now?
Kind of tough to answer as not really sure what state your models vs DB are in now after all that 
A question - what DB are you using, and do you have any data in it that you care about?
If not, my suggestion would be to simply zap everything in the DB, delete all your own migrations, then make the changes you need and run makemigrations and migrateagain.
(If you’re on SQLite … just delete the db file in your project folder - simple as that. It will get recreated when you run migrations)
For a good article on extending the user model in different ways, and which is right for you, check out How to Extend Django User Model
Oh, one tip that I usually do to make this stuff easy in dev is create a few management commands that will let you easily create some sample test data. That way, if you really need to, you can always just restart from scratch in dev without worrying about losing all that data you manually put in to test your functionality
(I often use the faker library for generating test data as well - this is quite useful)
To add to the previous answers - you can try using the dumpdata command to save your data in a form that can easily be reloaded into your database before dropping and recreating it. (If your system is so hosed that dumpdata doesn’t work, then you’ll have to use your database’s specific tools to backup / restore the tables you’re interested in saving.)
Also, if this is something you may want to (or need to) do multiple times across projects, see fixtures. We use dumpdata with natural keys to create reloadable images of “initialization data” in our projects. (Another vote here for faker - we’ve used it to generate data which we then save as fixtures to create reproduceable results.)
I am using the default db , Sqlite3. I don’t have any preexisting users in the database so I don’t mind removing that. However, I do have some data for the project model and gallery (just images). I can get all the data for those models from the google drive storage so I don’t have to start from scratch. Everything else is manually entered data so that shouldn’t be a problem.
So is dropping the whole database the best and most convenient way to solve this problem? Also, I have a live version of the website currently hosted on Python Anywhere. Will this move create any problems for the hosted version? Thank you very much.
Yes, you’ll likely need to replace your live database as well.
There are ways to recover from that type of mistake (deleting all the migrations), but it’s a manual effort that can take a lot of time and is subject to mistakes being made.
But, in the future, keep in mind that migrations are just as much a part of your project as any other file. You wouldn’t expect to be able to just arbitrarily delete files and expect your system to keep working - the same logic holds with your migration files. Once you learn more about how migrations work, then it becomes more practical to recover from such a move.
So to summarise, I should drop my local database by deleting the sqlite3 file. Then I should find a way to delete and replace the database on the live server as well?
If that’s the case, can you suggest a guide to help me the second part. Sorry If I’m asking too much, its just that I have no knowledge of this part of django.
Under the assumption that you’re going to be upgrading your live code from your local copy, yes.
If you’ve got a complete copy with your original migrations, you might be able to restore your migrations from your live copy and avoid all this work.
But I don’t know anything about Python Anywhere as a hosting service. I don’t know what your options would be regarding the replacement of your database.
My local to live workflow is to push changes made on the local computer to github before pulling those changes from github to pythonanywhere. Then from their bash console, I update my live website.
Now that you mention it, I could pull the project code from github (which is before all this mess) and won’t have to drop the database. I think that would actually work. How did I not think about this before? 
If you can roll back to before the mess and then reimplement the changes, it seems like it might be the best approach
I’ve not used pythonanywhere, though my guess is that your deployment setup should include an instruction to run any migrations. This is certainly how eg. Heroku works.
I finally solved the problem. I overwrote all the changes I made locally and pulled the “not messed up” version of the project from github. Thank You for helping me all the way. Really appreciate it.
1 Like