I am using two enviorments for my django project, dev and production. mostly I am working on dev, when I change fields in my models I am using south to migrate to the new models.
What I dont understand is how can I now transfter it to my production database ? What I am doing is committing my code into SVN and updating on production, then try to migrate.
Should I commit my migration directory and files ? or should I not ? it seems that it allways fail when trying to migrate on my production machine.
EDIT :
I have done additional tests. I have cleared my south histroy table and delete any migrations directories.
Now on my local enviorment I run : python manage.py convert_to_south app_name
everything seems to work perfectly. I have now add an additional field to my model and run : python manage.py schemamigration app_name --auto
The new field was migrate into my database as expected. Now, I commited my migrations folders with the .py files (contains 0001-initial and 0002 for my new field)
on my dev enviorment I updated my tree which includes the migrations files. I run python manage.py syncdb. the south_migrationhistory table was created but enpty.
now I run python manage.py schemamigration app_name --auto and got :
"Nothing seems to have changed."
the south_migrationhistroy is still empty..... I have no clue what I am doing wrong here
You Should commit your migration directory and files. When you do an svn update, south now knows what to do with your new migrations.
South looks up a database table called south_migrationhistory to see what migrations have already been applied, and based on that applies the new migrations specified in the migration folder. If you do not checkin the new migration files, it will always end up with "No new updates".
Related
when i try to run python manage.py migrate i run into following error
Upon running python manage.py run migrations it says no changes detected. and when i runserver it gives me warning that i have unapplied migrations as well.i have been searching internet for two hours but got not solution. Someone knowing the solution please share :)
The table in your database that stores migration data to keep track of what has been applied is out of date. Try running python manage.py migrate --fake
Try python manage.py makemigrations [app name] and if still, this does detect changes then delete the folder named migrations which is inside your application folder and then use this python manage.py makemigrations [app name]. Once migration happens successfully do the python manage.py migrate.
Don't Try This at Home
I faced this issue, i make two changes,
change AUTH_USER_MODEL, so i have one migraiton about it
second one add new field for my folder_model(migration name: folder_model 0021)
When my first migrate attempt(I already run makemigrations commands on local so i have migration files), it says;
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'
This error reiases because i change the AUTH_USER_MODEL in the middle of the project, normally you have to remove your database and fresh start from the beginnig(also truncate migrations etc.), according to Django doc -> https://code.djangoproject.com/ticket/25313
To fix this issue, you don't have to delete all migrations on db, just delete the migrations about admin(not from project just database)
After that just run
python manage.py migrate
It throws relation "django_admin_log" already exists. For this issue, run:
python manage.py migrate --fake
That's it, but not completely. Make fake migration act like you already make your all migrations successfully and save these on db. The issue came here that i have another migration about folder_model 0021 and with fake migration it doesn't applied to my database table but saved to db_migrations table.
So fix this issue, delete the folder_model 0021to database migration table (just 0021 not all folder_model migrations).
After delete just run python manage.py migrate
Everything is fine!
Should I keep django migrations files in a git repository? In a developers team, how they manages their database changes.
For example, Tom has made changes in their models, and ran makemigrations and migrate, his database now has changed, as well his migrations files, keeping his migration story.
Meantime, Bob has made changes too. He has his migration files that are about another models, He ran makemigrations and migrate commands, and his db changed.
Tom and Bob are working in the same app, so, They share the same migrations files. And the same db too.
So, what will happen when Bob push their code to git repo, and later Tom pull or fetch it from git repo? The migrations files will be mixed and their stories will be broken. Also, what about with the db itself, if it is a sqlite file, should I keep it in git repo?
You should absolutely keep migrations in your repo! With some projects, it makes sense to include initial data or other functions in the migrations by editing them, so setting up each developer's environment by automatically generating them from models.py won't work for every project.
If Tom and Bob both make changes that are independent of each other (Tom adds one field, Bob adds another), the migrations files will work when you create a merge migration. Tom and Bob may have to coordinate if they conflict:
$ python manage.py migrate
CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0002_mymodel_my_field_tom, 0002_mymodel_my_field_bob in myapp).
To fix them run 'python manage.py makemigrations --merge'
$ python manage.py makemigrations --merge
Merging myapp
Branch 0002_mymodel_my_field_bob
- Add field my_field_bob to mymodel
Branch 0002_mymodel_my_field_tom
- Add field my_field_tom to mymodel
Merging will only work if the operations printed above do not conflict
with each other (working on different fields or models)
Do you want to merge these migration branches? [y/N] y
Created new merge migration /myapp/migrations/0003_merge_20170517_1445.py
Here's a good read:
https://www.algotech.solutions/blog/python/django-migrations-and-how-to-manage-conflicts/
You should keep migration files in git to make sure database schema of all developers are in sync. Later these same migration files are used to migrate production database.
Any developer can create their migration file and add to version control and push to remote server. Django's migrate command detects new migrations and applies them to database.
In case two developers are working on same app and both of them create migration, django will create a merge migration file just like git creates a merge commit. This merge migration will make sure there are no conflicts in database schema and their database is in sync with latest the commit.
https://gist.github.com/mhipo1364/a55da230e1ec80bfab70e9650637bb15/revisions
Re-Generate Migration
To merge exist migration files into one file:
Remove django_migration records table (manually)
Remove all migration files
run python manage.py migrate --fake command
run python manage.py makemigrations command
run python manage.py migrate --fake-initial command
run python manage.py migrate contenttypes command
and finally, for chacking if everything is just fine, run python manage.py migrate command
If changes are on different models best way to handle them would be
makemigrations with -merge flag
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>
I have screwed up my database so I tried to redo it. I did:
1) deleted all tables via sql
2) deleted the migrations folder
So when I now do manage.py makemigrations myapp it is creating the migration folder and the initial.py file, which looks fine. Also the __init__.py is there. However, if i do manage.py makemigrations myapp I always get the message "No migrations to apply."
I looked up the database in the shell and the tables are not there.
I am using Django 1.8.
Django keeps track of all the applied migrations in django_migrations table.
So just delete all the rows in the django_migrations table that are related to you app like:
DELETE FROM django_migrations WHERE app='your-app-name';
and then do:
python manage.py makemigrations
python manage.py migrate
Django keeps track of all the applied migrations in django_migrations table.
So, you can follow this method:
Delete the related rows from django_migrations.
run python manage.py migrate.
I usually ran into that issue myself. Here is the workaround I found:
Replace your database sqlite3 with this
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': '<your_username>$<your_database_name>',
'USER': '<your_username>',
'PASSWORD': '<your_mysql_password>',
'HOST': '<your_mysql_hostname>',
}
}`
The fill in for can be found in the databases tab on your Pythonanywhere dashboard.
Push it to github from your Terminal and pull it down from Pythonanywhere Bash again. You may have to add this on Bash Console: pip install mysqlclient
As #Anush mentioned, Django does keep track of all of the migrations in the django_migrations table. As mentioned, you can use raw SQL to remove the migration row to reset Django's migration history for the concerned app.
DELETE FROM django_migrations WHERE app='my-app';
If you are uncomfortable deleting rows like this, then you can use Django's management command replacing my-app for the name of your app.
python manage.py migrate --fake my-app zero
That command will remove the migration history rows from the database leaving you to start your migration again from scratch. You will then need to:
Delete all of the migration files within your app's 'migrations' directory but ensure that the __init__.py file remains.
Ensure that your app's data models are set up as you need them
Make the migrations again with the command python manage.py makemigrations {your_app_name}. This will create the 0001_initial.py file within your app's migrations directory.
You will not be able to actually migrate the initial database migration because the database table already exists, so you will need to fake the migration with the command, python manage.py migrate my_app --fake-initial
Instead of run:
python manage.py migrate
just run:
python manage.py migrate --run-syncdb
If you have many problems and require a solution
Create a database backup (more than one if necessary)
My solution was to run the following query in the SQL shell
drop database database_name with (force);
This completely removes the database, be careful
It solved the error for me
Greetings
After running into this problem on Django 3.0 I spent an entire day troubleshooting this. Sharing this so that others would not need to. Most of the times running
python manage.py makemigrations
python manage.py migrate
Should solve the problem. I followed the above step after deleting the files in migrations folder (except init.py), however I was not able to solve the problem. I found that every time you run makemigrations, a python file called 000x_xxx.py is created in the migrations folder. I looked inside the file and found that all my required changes were there but it also had other create table operations that I did not need (i.e those tables had already been created). If you run migrate with --fake or --fake-initial, the whole execution will be faked (i.e executed without actually making any change in the database).
To solve the problem I opened the generated 0000x_xxx.py file and deleted the changes I wanted to make in the database and ran "python manage.py makemigrations" again. This created a new migration file with the changes I wanted. After that I ran the following command.
python manage.py migrate --fake-initial appname
This solved the problem. Not sure if this should be this complicated.
I have just started using South (finally) and it is really a great tool. I started a project and did a few initial migrations to get the feel of South. I have now just git cloned this project onto a new machine. In do not have the database data, as there was no data enter yet.
My question is what are the steps to rebuild the database?
I have tried:
./manage.py schemamigration <myapp> --auto
and:
./manage.py migrate <myapp>
But it says nothing seems to have changed.
Do I also need to run an initial syncdb? Will the South migration history be intact?
Any help much appreciated.
Yes, you need to run syncdb initially to load the south migration history table
Edit your settings.py and put ‘south’ into INSTALLED_APPS (assuming you’ve installed it to the right place)
Run ./manage.py syncdb to load the South table into the database. Note that syncdb looks different now - South modifies it.
Run ./manage.py convert_to_south myapp - South will automatically make and pretend to apply your first migration.
See Converting an App