We should have a viewpoint of when to use django signals and when to not
fgregg opened this issue · comments
Forest Gregg commented
these powerful features are causing a bit of headache for @smcalilly and @xmedr in CCFP. we have to use them, and are using them well enough in Councilmatic land.
let's maybe create some guidance for this.
Sam McAlilly commented
- when to use them?
- when you need to hook into a model that you don't control (see councilmatic -- couldn't stuff custom code into their save methods)
- signals to add/remove a many-to-many field (see workplace app @antidipyramid)
- fallback for when you can't use the model.save method
- when to not use them?
- when you can encapsulate the logic in a custom save method
- when you control all of the relevant models
- batch operations / update doesn't trigger a signal
percolation in elasticsearch signal. is there a better way to do this without signals?
best practices:
- observability, should we keep them in a signals.py file? it's not always obvious from the model when the signal exists there, and the model is the first place you'll look when debugging model stuff.
- if you're using signals, it should be documented in the readme.
there are different POVs, but we still need some guidance.