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
Related
one of my fellow developers checked out from master and created new models for our website. He ran makemigrations, then ran migrate which obviously created the tables we wanted.
However, he never committed his changes to github and he altered the production database. So when I went in to add a table today, when I ran makemigrations it the terminal listed several tables that I knew already existed...I was like "YOLO!" and ran the migrate command anyways and it puked.
So, since the migrations file isn't in my migrate folder, django thinks it needs to create those tables...then it goes to create them and pukes because they're already there.
The other developer is out of town visiting family and can't commit the file.
How do I get this set straight? I think I need to run ./manage.py migrate my_app --fake
But I don't completely understand what that does so I don't want to take the YOLO route and really mess things up...
OK, I promise everybody out there that I have been working on this problem for 9.5 hours today. Turns out this was the answer:
Django migrations : relation already exists
However, there were some spelling/syntax errors that made it difficult to understand that this other person had the same problem as me.
to reiterate the solution:
type: ./manage.py makemigrations your_app
Navigate to the my_app/migrations folder and open the migrations file that was just created (usually looks like '0005_modelsandstuff_blablabla.py"
Delete the models that DON'T ALREADY EXIST. Save the file and close
type: ./manage.py migrate your_app --fake
this will then sync what is in the database now with your models schema without altering any of the actual database
type: ./manage.py makemigrations your_app
type: ./manage.py migrate your_app
And that's it! Everything is all synced up again. Just as a quick jab I would like to say JavaScript sucks. Thanks.
Following these steps should solve your problem.
Backup your database
Stash your changes (so that only the missing schema changes are picked up)
Create the migrations (this creates the already applied schema changes)
Run migrate with --fake (this will fake apply the already done schema changes)
Apply your changes
Create the migrations
Run migrate
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!
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 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".
I changed a lot in my models.py, including deleting a lot of fields, and renaming a couple of classes. schemamigration --auto worked fine, but trying migrate threw a bunch of errors.
All my code is currently in development so I don't mind too much losing the data. So I want South to "unconvert" or "unmanage" an app so I can rebuild all the tables with syncdb again.
Or I could delete all migration list and do schemamigration --initial again.
Yes, just delete the migrations and run schemamigration --initial again. You should do that anyways as normal course before moving to production. If you've already gone to production at least once, don't delete all the migrations -- just the ones you've created in the current development cycle and then run schemamigration --auto to get just one migration instead of the potential multiple ones.
FWIW, to "unconvert" an app using South, you merely delete the "migrations" directory, but in this scenario, there's no need.
UPDATE
It was pointed out that if you have already migrated your app, and you delete all the migrations and generate a single new one, South will complain about migrations still in the database. The actual process you should follow is:
Rollback to the just before the newest migration you created in the current development cycle. For instance, if you were already at 0005 and you created three new migrations for the development work you were doing (now at 0008), you would rollback to 0005. If all of the migrations are new, you rollback to zero:
python manage.py migrate yourapp zero
Delete all of the migrations you're going to merge. In the above example, that would be 0006, 0007, and 0008, or for a new app, everything in the migrations directory but __init__.py.
Generate a new migration to cover the ones you just deleted. If it's a new app, use --initial, or if it was a pre-existing app, use --auto.
python manage.py schemamigration --initial yourapp
Migrate
python manage.py migrate yourapp