[Django] #27312: Current solution to prevent signals from executing on fixtures is non ideal
Django
-------------------------------+------------------------------
Reporter: Álex Córcoles | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Severity: Normal | Keywords: fixtures signals
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27312>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Álex Córcoles | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Keywords: fixtures signals | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Simon Charette):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27312#comment:1>
Django
Reporter: Álex Córcoles | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Keywords: fixtures signals | Triage Stage: Unreviewed
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27312#comment:2>
Django
Reporter: Álex Córcoles | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Keywords: fixtures signals | Triage Stage: Unreviewed
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
loading isn't DRY
-------------------------------------+-------------------------------------
Reporter: Álex Córcoles | Owner: nobody
Cleanup/optimization |
Component: Core (Other) | Version: 1.10
Severity: Normal | Resolution:
Keywords: fixtures signals | Triage Stage:
| Unreviewed
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* type: Uncategorized => Cleanup/optimization
* component: Uncategorized => Core (Other)
Comment:
In a past project, I used the [http://stackoverflow.com/a/15625121/5112
@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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27312#comment:4>
Django
loading isn't DRY
-------------------------------------+-------------------------------------
Cleanup/optimization |
Component: Core (Other) | Version: 1.10
Keywords: fixtures signals | Triage Stage:
| Unreviewed
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* status: new => closed
* resolution: => needsinfo
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27312#comment:5>