CODEWITHSUNDEEP
djangodjango-south
Marc Hughes
Marc Hughes

Reputation: 5858

Why does South try to drop a column I'm trying to add?

I've got a simple migration that looks like this:

class Migration(SchemaMigration):

    def forwards(self, orm):
        db.add_column('activities_newsitem', 'related_story', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Story'], null=True, blank=True),keep_default=True)

Unfortunately, it fails and I'm not sure why. Below is the output. Notice, that it runs the add column query just fine. In fact, when I look in the DB, the column is correctly there.

But for some reason, it's running a drop column afterwards and that's what fails. Why is it doing that?

DEBUG south execute "ALTER TABLE `activities_newsitem` ADD COLUMN `related_story_id` integer NULL;" with params "[]" (generic.py:145)
DEBUG south execute "ALTER TABLE `activities_newsitem` ADD CONSTRAINT `related_story_id_refs_id_3d3841088db0fdb0` FOREIGN KEY (`related_story_id`) REFERENCES `projects_story` (`id`);" with params "[]" (generic.py:145)
DEBUG south execute "CREATE INDEX `activities_newsitem_related_story_id` ON `activities_newsitem` (`related_story_id`);" with params "[]" (generic.py:145)
DEBUG south execute "ALTER TABLE `activities_newsitem` ADD COLUMN `related_story_id` integer NULL;" with params "[]" (generic.py:145)
DEBUG south execute "ALTER TABLE `activities_newsitem` ADD CONSTRAINT `related_story_id_refs_id_3d3841088db0fdb0` FOREIGN KEY (`related_story_id`) REFERENCES `projects_story` (`id`);" with params "[]" (generic.py:145)
DEBUG south execute "ALTER TABLE `activities_newsitem` DROP COLUMN `related_story_id` CASCADE;" with params "[]" (generic.py:145)
 ! Error found during real run of migration! Aborting.

 ! Since you have a database that does not support running
 ! schema-altering statements in transactions, we have had 
 ! to leave it in an interim state between migrations.

Thanks for any help

Upvotes: 2

Views: 261

Answers (1)

mgrouchy
mgrouchy

Reputation: 1961

It looks like it tried to run your command twice. If you look in your migrations folder, do you have 2 of the same migration? It may do this if you run the create migration command twice without actually migrating.

Did you run your command twice by accident? You can check this out by opening up a database console and checking if your migration is in the south_migrationhistory table.

Assuming you are using a unixy system(OSX/Linux), From the command line:

mysql -u username -p password

then

select * from south_migrationhistory;

Is your migration in there?

If so your task is done, and you can move on. If it isn't and your activities_newsitem table has the column, you need to fake the migration to get your south migration history up to date.

To fake your migration:

python manage.py migrate activities --fake 0001

where 0001 is the migration number(all migration files are prefixed with a number).

Upvotes: 1

Related Questions