Django Field Rename Migrations and Test Cases

Is there some trick to running Django test cases when you've got a RenameField later in the migration-stack? I feel like this has to be some obvious thing I'm missing...

With a migration (say 0058_big_restructure.py) which does this:


migrations.RenameField(
model_name='rfsource',
old_name='source_name',
new_name='follow_source_name',
),

and a previous migration, (say 0006_long_ago_change_that_populates_some_other_field.py) which doesn't explicitly reference the source_name field, but does query the DB for records in the modified table:


def set_map_numbers(cls):
for i, inst in enumerate(cls.objects.order_by('id')):
inst.number = i
inst.save()

def set_all_map_numbers(apps, _):
set_map_numbers(apps.get_model('shogunconf', 'RFSource'))
...
operations = [migrations.RunPython(set_all_map_numbers)]
...

the 0006 migration will begin failing *after* the first test-case (with either Django TestCase or TransactionTestCase) with column shogunconf_rfsource.source_name does not exist. That is, the migrations succeed for the first test case, but then the *second* test case fails during migrations as the 0006 migration is trying to read the older source_name field, while the test DB now has the newer follow_source_name in the table (despite still having 51 migrations to run before hitting that renaming of the field).

AFAICT the RenameField *should* be able to reverse the operation (at least, the code seems to suggest it should). My guess is that there's some weird interaction between the TestCase/TransactionTestCase and the migration/rollback in the test framework that's leaving my test_db in this half-migrated state.

Comments

Comments are closed.

Pingbacks

Pingbacks are closed.