Checking raw argument to prevent signals from executing during fixture loading isn't DRY

[Álex Córcoles]

We have some signals that create information when some models are added/updated which should not be run when loading fixtures.

We have had to use the raw argument to disable each signal when fixtures are being loaded, and it works, but it is not ideal as we have to repeat the same bit of code in each affected signal (basically "if raw: return"), which is duplicated code (which we do not like) and code we have to test (which adds overhead- esp. as the code contains a conditional and messes with coverage).

I think it would be better if you could state that you only want to connect your signal for non-fixture operations- this way it would be 100% declarative and not require any testing).

Other alternatives could be provided as not running signals on fixtures by default, which I think it's a nicer default, but might be controversial.

[Simon Charette]

Is there a reason you can't use data migrations (RunPython operations) to load your fixtures?

Models provided in data migrations through the apps kwarg are not connected to any signals so you should be able to achieve what you're after this way. Please give #24778 a try if that works for you.

Not running signals during fixture loading is not only controversial, it's breaking backward compatibility.

[Tim Graham]

You could probably write a custom @receiver decorator that takes care of if raw: return. May Django should include that, although I agree with Simon that using data migrations is more common these days.

[Álex Córcoles]

Replying to Simon Charette:

Is there a reason you can't use data migrations (RunPython operations) to load your fixtures?

Hmmm, in this case we hit this because we wanted to quickly load data from production (running PostgreSQL) into our development environments (using SQLite) for quick reproduction of a bug, dumpdata/loaddata seemed the most convenient way to do this.

I don't feel that migrations are the right solution there, although I have to admit that the use cases for dumpdata/loaddata might not be very common and might be quite narrow, and that my knowledge of migrations is lacking so this might very well just be my ignorance.

Not running signals during fixture loading is not only controversial, it's breaking backward compatibility.

Yes, I agree with that- it's what *I* would personally prefer, but I know that is not an universal view and I'm not the law here :). But maybe being able to signals.post_save.connect(...ignore_on_fixtures=True...) would be very nice without breaking anything. Or maybe an opt-in setting and deprecation schedule for the former behavior.

You could probably write a custom @receiver decorator that takes care of if raw: return. May Django should include that, although I agree with Simon that using data migrations is more common these days.

That's also a solution I considered- and seeing that you guys suggest it give it more weight, but of course it would be much more convenient for me to have this built-in to the framework.

All in all, not really a deal-breaker for me, so feel free to close if this has not enough importance.

[Tim Graham]

In a past project, I used the ​@disable_for_loaddata decorator.

I don't have a strong feeling about whether some solution should live in Django. Maybe you'd like to make a proposal on the DevelopersMailingList to get other opinions.

[Tim Graham]

I guess we'll reopen this if someone wants to start a mailing list discussion to gather a consensus about what, if anything, should be done here.