I switched database names, and now my Django models are out of sync with my database tables. What is the command to force Django to perform all migrations to sync up the models and the tables? I don't want manage.py migrate --fake.
I fixed this by manually deleting all the migrations and running makemigrations again to get a new initial migration file. Then, I went into my database and manually dropped all the tables that Django created in the app. Finally, I deleted all of the rows in the table django.migrations that included the app name. After all that, I ran manage.py migrate and the database was in sync.
When you change something in your models you must execute:
python manage.py makemigrations
for creation new changed schema of your models. Then:
python manage.py migrate <app_name>
Related
I am working with Django v4.* which I connected it to Postgres DB on the localhost,
I have created my model (Article) then makemigrations then migrate
then I have changed the model by adding extra field, as a result it didn't take effect so I have deleted the table and all the migrations files in articles/migrations folder apart of the __init__.py file, then I did makemigrations then migrate it create a new file 0001_initial.py but its not creating a new table into the DB, unless I drop the whole DB, which is not ideal in the production env!
I am wondering why Django is unable to create the table back again? and how I can get it created as a new table?
Roll back to your initial migration by running below command:
python manage.py migrate --fake <appname> 0001
Followed by:
python manage.py migrate <appname>
Just delete your database with
python manage.py flush
And delete migrations files
You may have mistyped the directory in the terminal
When I do python manage.py migrate the desired model doesn't appear in my postgres database. I previously deleted all the tables and then migrated it again and it worked but I don't want that because I have loaded many data in the tables that I will have to load again. How to migrate only a certain model.
You need to delete the migration files in app/migrations first and then run makemigrations before running migrate:
python manage.py makemigration
Also make sure to delete the corresponding lines in your django_migrations table.
To drop table I used that command:
python manage.py dbshell
.tables
DROP TABLE table_what_i_drop;
Then I tried:
python manage.py makemigrations
and:
python manage.py migrate
but the table wasn't created.
I deleted migrations folders from all apps and the dbsqlite3 file and tried again makemigrations and migrate, but databases wasn't created. Now when I tried:
python manage.py dbshell
.tables
there are no tables for any of my apps. I know that losing tables is my fault, but how I can make all databases from the beginning?
There are two steps in migrations - make migrations and migrate.
makemigrations creates the migration file based on database changes.
migrate runs the migrations and makes the database changes. It also logs what migrations have been run in the table:
django_migrations
You deleted the migrations folder,but there will still be an entry in django migrations saying that your previous migrations have run.
So to fix this, go to the django_migrations table and remove the entries related to your app (there will also be entries for Django tables, such as auth and contenttypes, so don't delete those)
(Alternately just delete the whole sqllite database and start from scratch if you don't mind loosing data in the database)
So I am a newbie to Django and I had added a field to a model.py and that created issues in Django.
I learned I needed a migration tool, and used south. Turns out south has issues with sqlite. So I configured Django settings for MYSQL. I can add data to the DB (MYSQL)
I deleted the db.sqlite3 file , but it comes back after ever syncdb.
When I run syncdb it says:
Syncing...
Creating tables ...
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
Synced:
> django.contrib.admin
> django.contrib.auth
> django.contrib.contenttypes
> django.contrib.sessions
> django.contrib.messages
> django.contrib.staticfiles
> south
Not synced (use migrations):
- accounts
(use ./manage.py migrate to migrate these)
So my questions are:
1. Changing to MYSQL did not remove the mid migration that south failed on, as I hoped it would. What are my options now in order to deal with this
Do I even have to do anything, or can I keep working on my app or is this mid migration something to address? I ask because the new MYSQL DB seems to have the new field I added, which was why I wanted to migrate in the first place. So you can see my confusion...my migration broke, but now with MYSQL, the fields are fine, but Django still thinks im in the middle of a migration. Why is this and what is the recommendations?
thanks
I have fought many many many (many) times with Databases & Migrations & South... I hope this information helps you to fix your issues and save you some hours of hard work
Migrating accounts app
I have a question here, is accounts the name of your app ? Or is it an external app ?
The accounts app seems to be managed by South, that means that It won't be synced with the command python manage.py syncdb, you will need to migrate it by yourself with:
# This command generates the migrations file
python manage.py shchemamigration accounts --initial
# This command use the migrations file and apply the changes to the DB
python manage.py migrate accounts
# --initial is used only in the INITIAL migration
# If you modify the models on the accounts app and want to migrate again
# You will need to
python manage.py shchemamigration accounts --auto
python manage.py migrate accounts
Keep an eye on your migrations
If you check the folder migrations following the standard structure it is yourapp/yourapp/migrations
If you delete your database, remember to delete your migrations files, is better to start over unless you need to save the Database changes
Make sure that your Database and your migrations are synchronized, if they are synchronized add some changes to the database will be easy
Some times, although you're using south, when you do python manage.py syncdb your app will be synced, I will explain which problems can come from here:
Your app models are created in the database with the command python manage.py syncdb
After 1. you do python manage.py schemamigration --initial and it will create the initial migrations
Now, if you try to do python manage.py migrate yourapp it will fail because the tables has already been created, so you need to fake the initial migration with:
python manage.py migrate yourapp --fake
and from here you could use south without problems
How to "restart" the database
This process will empty the database and delete all the migrations, take care if you have some data you want to save
Sometimes you will mess with the migrations, and depending on the issue, it can be faster to drop the database and start the migrations again:
python manage.py dbshell
# Next 3 lines inside the MySQL console
>> drop database yourappdatabase
>> create database yourappdatabase
>> quit
# Delete all the migrations within the migrations folder
rm yourapp/yourapp/migrations/00*
python manage.py syncdb
python manage.py schemamigration yourapp --initial
python manage.py migrate yourapp
How to save informations from the database
Some times when you're starting a new app you will delete/create the database many times, and to avoid typing again and again data on the models, it could be useful to create migrations from some models with:
python manage.py dumpdata yourapp.ModelName > file.json
To reload this data again you just need to:
python manage.py loaddata file.json
I have changed the Django models, and I use the Django schemamigration to update the database. But, when I do python manager.py migrate app， it throws this error message：
_mysql_exceptions.OperationalError: (1050, "Table 'forum_user' already exists")
Then the table that django south is trying to create already exists and doesn't match the state of your database.
If this is the first time you're migrating, remember that before you make schemamigration changes, you must set the initial state via schemamigration myapp --initial and migrate app --fake to match the database to the south database state.
manage.py convert_to_south myapp also does the above as a convenience method.
To start using south...
Make sure your django tables match your current database tables exactly - if you planned to add or remove columns, comment those out.
Run python manage.py schemamigration myapp --initial
Run python manage.py migrate myapp --fake
Make changes to your django model
Run python manage.py schemamigration myapp --auto
Run python manage.py migrate myapp
Update
Note django 1.7+ ships with migrations and south is no longer in use.
There are only two commands worth noting..
manage.py makemigrations (handles --initial)
manage.py migrate
Written by the same author as South, crowd funded. Go django.
I just fixed a duplicate table issue locally and wanted to document my workflow to help others.
The key to success was creating an --empty migration before the new models are added. The flow:
Merged in another persons work that excluded info on a model I have locally.
normal schemamigration --auto was adding a table/model again and caused "already exists error".
Solved by commenting out the new model and running an empty migration via clear; python manage.py schemamigration --empty APPNAME MIGRATION_FILE_NAME. This creates a "declaration" of the state of the models with no forward/backwards commands. Be 100% sure the current state of models (python files) and database are in sync!!! This most current migration will be used for the creation of a differential to migrate correctly (next).
uncomment the new model and run clear; python manage.py schemamigration APPNAME --auto to create the true and desired differential off (uses the --empty migration just created). The new migration will have forward/backward commands that should be appropriate for your new model. Review...
finish off with clear; python manage.py migrate
The lesson learned is that --auto looks at the last APP+migration file to create a forward/backwards diff. If the last migration does NOT have in the dictionary a model you have in DB it will be created again causing an "already exists" error. Think of the dictionary as a contract between Django and the DB stating "here's what everything should look like". The migration can include commands that create duplicate tables and will only be exposed during ```migrate`` command.
The above info should fix the problem. Presented in part to help people and also for review in case I am doing something foolish.