Ticket #805 (new defect)

Opened 3 years ago

Last modified 3 years ago

Failure in post_syncdb signal handlers mask failure in migration

Reported by: dpisoni@… Owned by: andrew
Priority: major Milestone:
Component: migrations Version: 0.7.3
Keywords: Cc:

Description

So in migration.migrators.Forwards.migrate_many() is this code:

finally:

# Call any pending post_syncdb signals
south.db.db.send_pending_create_signals(verbosity=self.verbosity,

interactive=self.interactive)

I'm a little unclear why this is in a finally block and not just the last call in the try block. If an exception is raised, doesn't that mean that the migration failed and the transaction was rolled-back? If so, why send the post_syncdb signals?

In my case, what is happening is that I have to go mucking around with the debugger to figure out why my migration is failing because the exception I am causing is "lost" when the syncdb handler raises its own exception.

So why is this in a finally block, anyway?

Boring details:
The specifics for my case involve a new model created, data copied from another model to it, then the old model is destroyed. I made an error in the data migration bit, so it raises, but because the transaction is rolled back, the signal goes out, it attempts to remove entries from django_content_type that I'm referring to in another model that is also supposed to be deleted by this migration.

Change History

comment:1 Changed 3 years ago by andrew

It's in a finally block as only models that have already sent create signals get affected by this call - if your migration makes 10 tables, and the last one fails, only the other nine get the signal sent.

That said, this is still a relic of South's mostly model-agnostic past, and back when there were a lot of people screwing up migrations by hand. However, I'm not sure if changing the current behaviour is going to break anyone's code.

Note: See TracTickets for help on using tickets.