CODEWITHSUNDEEP
pythondjangomigrationdjango-southdatabase-migration
CodeTalk
CodeTalk

Reputation: 3657

Issue migrating in Django with South (Mysql)

I just had an issue where south seems to be confused between two migrations.

Last (4) migrations: imgggggg

I had a table:

class VulnFuzz(models.Model):
    fuzzVector = models.CharField(max_length=200)
    FkToVulnTbl = models.ForeignKey(Vuln)

I wanted to change that table to something else:

class VulnFizz(models.Model):
    fizzVector = models.CharField(max_length=200)
    FkToVulnTbl = models.ForeignKey(Vuln)

The problem is, when I ran: 

python manage.py schemamigration Scanner --auto

it says to then migrate it, so I do using:

python manage.py migrate Scanner

It says:

Migrating forwards to 0041_auto__del_field_vulnfizz_FkToVulnTbl.
 > Scanner:0032_auto__chg_field_vulnfuzz_FkToVulnTbl__del_index_vulnfuzz_FkToVulnTbl
FATAL ERROR - The following SQL query failed: DESCRIBE `Scanner_vulnfuzz`
The error was: (1146, "Table 'vulnawarefinal.scanner_vulnfuzz' doesn't exist")
 ! 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.

! You *might* be able to recover with:   = CREATE INDEX `Scanner_vulnfuzz_30a95dc2` ON `Scanner_vulnfuzz` (`FkToVulnTbl_id`);

I had already tried running the suggestion of before changing tables:

CREATE INDEX `Scanner_vulnfuzz_30a95dc2` ON `Scanner_vulnfuzz` (`FkToVulnTbl_id`)

But that didnt fix it.

I am at a loss now, how should I go about fixing this? Or should I redo the whole db?

Thank you

Upvotes: 3

Views: 280

Answers (1)

Simeon Visser
Simeon Visser

Reputation: 122326

You're at migration 31 and you want to migrate to 41. The error occurs at migration 32 so the problem is not with your current described code change and the associated migration 41.

Migration 32 expects table Scanner_vulnfuzz to be there but it's not. In other words: your database is not in the state that South expects it to be.

You may be able to recover by migrating back to the migration that creates the table and then running all migration again. Otherwise you may have to recreate the database and run syncdb and migrate again from the beginning.

Upvotes: 2

Related Questions