Kevin RiggleAnybody on here have strong opinions about using #python #Django signals versus overriding e.g. a model’s save() method? I need to cache a parsed version of a large TextField, & so I’m considering a singleton RerenceManager class that listens for model change signals and parses the references out of the relevant text field for use by view code and templates. But I guess I could also override the save() method on the model and have it call an update_references() method on the ReferenceManager
Raymond Neilson@kevinr Been a while since I've used Django at all, but when I did, every time I even thought about overriding `.save()` I got bitten, *hard*
@delta_vee haha that’s good to know (and certainly is not in conflict with my experiences)
Jonathan Biemond@kevinr Perhaps a third option is helpful? Django Lifecycle Hooks works somewhat similarly to signals, but they are defined on the model itself. https://rsinger86.github.io/django-lifecycle/
Dan Sloan@kevinr There’s nothing explicitly wrong with overriding save, but i tend to avoid it unless I’m actually modifying the behaviour of save itself rather than triggering a separate action. For the latter, a pre or post save signal seems more of a natural fit.
Either way keep in mind that nether one will trigger if you do a bulk create/update db operation.
Thomas Steen Rasmussen@kevinr both work but signals can be tricky to understand/find/debug. Especially when overused they can turn an otherwise nice codebase somewhat spaghetti-ish :/
Benjamin Balder Bach@kevinr I agree with @tykling - I'd only use signals if I'm authoring an external library and know that's what I want... otherwise, I'd stick with either using .save() in my own projects OR even better, write an explicit method and call it separately from .save().
Having magic in .save() can get out of hand. And you need to be careful with things like the `update_fields=...` keyword argument.