OK, this is driving me nuts. I'm trying to remove and reset all my south migrations in my DEV environment for two apps, and start again with a clean slate, as my migrations files list was getting very long and I don't need them, as the models are constantly changing, and it's just DEV. Whatever I try, South constantly complains that the DB tables are already there.
Going on this answer on SO, I first remove my migrations dir entirely from each app:
rm -r <my-app>/migrations
No problem. Then reset the south tables:
python manage.py reset south
Again, no worries.
Now tell south that I want those apps managed:
python manage.py convert_to_south <appname>
All seems fine, it even creates the initial migration and runs the --fake:
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate CC
- Soft matched migration 0001 to 0001_initial.
Running migrations for CC:
- Migrating forwards to 0001_initial.
> CC:0001_initial
(faked)
OK, so according to my (incorrect) understanding, I now have my existing tables managed by south. South knows that the tables ALREADY exist, as we ran initial as --fake.
Now I add a new field to a model, run schemamigration then migrate on that new schema, and guess what, South complains that the tables already exist.
django.db.utils.DatabaseError: table "_south_new_CC_coveredcall" already exists
What the hell? What on earth am I doing wrong?
Caveat: it's late here and I'm tired, but it will be something along these lines:
Rather than telling South that you want to migrate an existing app (which implies a schema exists), you can fake-zero the apps, delete the migrations and make a new intitial one for each app and fake apply it. That basically gets South to replace multiple migrations with one per app
$ ./manage.py dumpdata myapp1 myapp2 > dumped.json # just in case!
$ ./manage.py migrate myapp1 zero --fake
$ ./manage.py migrate myapp2 zero --fake
$ rm /path/to/myapp1/migrations/.py*
$ rm /path/to/myapp2/migrations/.py*
$ ./manage.py schemamigration myapp1 --initial
$ ./manage.py schemamigration myapp2 --initial
$ ./manage.py migrate myapp1 --fake
$ ./manage.py migrate myapp2 --fake
The new 0001 migrations for myapp1 and myapp2 will have the same result as the multiple ones that actually created the existing schema, so all will fit just fine (as long as there have been no custom SQL migrations etc)
Try this code:
rm <app>/migrations/*
python manage.py schemamigration <app> --initial
python manage.py migrate <app> 0001 --fake --delete-ghost-migrations
Thanks to all who contributed - it turns out that as I'm using SQlite in dev, It's this that is causing all the issues. See another question on SO for clarification. Answering my own question here as it may be useful for others - I'm switching to mySQL, as the issue I stated above doesnt exist in my PRD env, which uses mySQL. Migration all works seamlessly.
Related
I have a production web project running with a decent amount of data in the MySQL db. I am trying to update the database with some changes to an app called "enterlink." I've made new elements in the existing models and created new models altogether. Before this migration, I have never touched the schema of the db since originally running syncdb to create it. When I run: "python manage.py makemigrations enterlink" the below output appears(pic). My question is, why is this happening? The DB already includes all the models that it lists in the picture so why is it registering those lists of models? When I go to finish the migration by doing "python manage.py migrate" or "python manage.py migrate --fake enterlink" (pic again), I get an output shown but my database schema remains identical to the old db and any new code generates errors. Can anyone tell me what is likely the problem? I would be really appreciative of any advice. It's been very frustrating since I'm not sure what I'm missing.
What you have done is that you have ran the command python manage.py syncdb before running python manage.py makemigrations myapp and python manage.py migrate myapp. That is why syncdb created the database schema and the migration was faked because schema already exists. I will suggest to use python manage.py makemigrations myapp and python manage.py migrate myapp and not to use syncdb as its deprecated in Django 1.7.
If you change anything in your model, just run makemigrations and migrate command. Syncdb isn't necessary.
This question and relevant answers are intriguing me. Thus I want to share my experience on maintaining live database and migrations.
Tested in django1.5.5
Initializing the database:
./manage.py syncdb --noinput
./manage.py migrate
./manage.py syncdb
Now I have created the database.
Doing a migration for an app:
./manage.py schemamigration myapp --initial
./manage.py migrate myapp --fake
Now do necessary changes in your model
./manage.py schemamigration myapp --auto
./manage.py migrate myapp
Im newbie for schemamigration too, but i will explain how it works for me:
First you create app and then
./manage.py sycndb, so tables are created then you can
./manage.py makemigrations myapp --initial
so now initial migrations are created and you should apply them
./manage.py migrate myapp
now you can change your models : add,change fields, anything you want and then
./manage.py makemigrations myapp --auto
this will create migrations for changes and now you need to apply them
enter code here./manage.py migrate myapp
so this actually will create new tables in db
I'm deploying a project on a new development environment.
As I'm using South I did:
$ python manage.py syncdb --all
$ python manage.py migrate --fake
I used syncdb --all to apply actual state of models.
Then migrate --fake to mark all models as migrated.
But after that, my model is not on the last version (missing fields)
What am I doing wrong ?
I assume all my modifications have migrations.
If I do
$ python manage.py syncdb
It seems to create the first state since when I used South (that is expected)
But then
$ python manage.py migrate
Some tables appears as already created
Actually this, should have been fine for my case
$ python manage.py syncdb --all
$ python manage.py migrate --fake
Having to redeploy my app recently, I faced the same issue.
I just realized that I had a double initial migration on the model that were causing the problem
0001_initial.py
0002_initial.py
0003_auto__add_field_mytable_myfield.py
I simply deleted & renamed
0001_initial.py
0002_auto__add_field_mytable_myfield.py
Then redone the whole database deployment (obviously not forgetting to update the already applied migrations on my other hosts)
--fake option does not avoid errors while trying to create new migrations. It records that migrations have applied without actually applying them.
Also, you need --ignore-ghost-migrations or --delete-ghost-migrations to achieve what you are looking for.
To convert an existing project to south, you first need to convert the app
Now, if you have already run --fake, to recover, you can do this:
Go to ./manage.py dbshell
DELETE FROM south_migrationhistory WHERE id > 0; //Note that this would delete everything in the table.
If you want to remove migrations of a specific app,
DELETE FROM south_migrationhistory WHERE app_name = 'blah'
I have Django model that I already have initialized with south using ./manage.py schemamigration (appname) --initial. All was going well through this point, until I decided I needed another field. I added another field and tried to to migrate the change with ./manage.py schemamigration (appname) --auto, but it says:
- Nothing to migrate.
I made sure to migrate the initial changes.
Seems to be similar to the problem here, but the solution got me nowhere.
It's probably because between the --initial migration and the next schemamigration you have to persist the actual migration to the db issuing the command python manage.py migrate my_app.
After doing that first migration then you may add another field, do and schemamigration --auto and commit it to the db again by doing python manage.py migrate my_app
Hope this helps!
When I run ./manage.py syncdb it says not synced (use migrations). However, when I run
$ ./manage.py schemamigration myapp --auto
Nothing seems to have changed
$ ./manage.py migrate
blah blah, nothing to migrate
As per this thread, I tried resetting south to fix the problem. Here's what I did:
$ rm -r appname/migrations/
$ ./manage.py reset south
$ ./manage.py syncdb
(at this point it shows all apps as synced)
$ ./manage.py convert_to_south myapp
blah blah, App 'blog' converted.
$ ./manage.py syncdb
(at this point it shows myapp as not synced)
Running schemamigration > migrate has the same effect as before (nothing, still not registering as synced).
On the plus side, the app still seems to work fine, I'm just worried this could cause problems down the road. Any idea what's going on and how I can fix it? Is this even really a problem? I'm using SQLite3 and Django 1.4.2 if that helps.
This might not be a problem, after all. I just found this bit in the South docs which seems to indicate that South takes over that functionality. South "makes syncdb only work on a subset of the apps - those without migrations." ie it's okay for syncdb to show myapp as not synced because south is handling it separately.
I hang my south-noob head in shame.
when I do a syncdb I get the following error everytime:
Not synced (use migrations):
- deals
- analytics
(use ./manage.py migrate to migrate these)
And when I run sudo python manage.py migrate. I get the following
Running migrations for deals:
- Nothing to migrate.
- Loading initial data for deals.
No fixtures found.
Running migrations for analytics:
- Nothing to migrate.
- Loading initial data for analytics.
No fixtures found.
I highly appreciate your help
From the output, it seems like the database is already synchronized with the migrations. There are no problematic errors. (Although you shouldn't really be root to run the migrations.)
If you're looking into creating more migrations, use the south documentation, which usually is just running the following after you modify the models:
python manage.py schemamigration --auto <APP>
And then use python manage.py migrate to apply the changes.
It looks like migrations have been already passed. Check south_migationhistory table in db.
If you want to sync new db for apps which has migrations just disable south in settings.py.
Have you ran a schemamigration initial yet?
./manage.py schemamigration deals --initial
./manage.py migrate deals
if you get the error, db already excists do this:
./manage.py schemamigration deals --initial
./manage.py migrate deals --fake