#27312: Current solution to prevent signals from executing on fixtures is non
ideal
----------------------------------+--------------------------------------
Reporter: Álex Córcoles | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Severity: Normal | Resolution:
Keywords: fixtures signals | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------
Comment (by Álex Córcoles):
Replying to [comment:1 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27312#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.5fd5d683e7b362bed9f3bbba41563fda%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
