I work at a company where we have a pretty monolithic rails app that isn’t particularly well written. As a result we have callbacks scattered across many files that have widely assorted impacts. One issue that I’ve run across multiple times is trying to skip callbacks (all callbacks) when saving objects (things like sanitizing your db in a rake task?).
I do know about update_column and update_all, I’m just wondering about the potential for a flag that could be set on an instance, (maybe even class level?) and perfectly skips every single call back.
Code Example:
task.skip_all_callbacks
task.save!
=> true
Please let me know if there’s any interest in this idea or if it’s just plain stupid.
Setting a state on a class like can really cause a bad side effect (for example, you thought that the state was set to true in only one process but it’s affecting another process and so on). I don’t think it’s a good idea to create a flag on the class like that.
However, I can see it as an option to save, so you’d do:
model.save!(skip_callbacks: true)
but then, I feel like I wouldn’t want to encourage you to use/implement that just because you could ended up skipping a crucial callback for that model and breaks the model integrity.
I feel like instead of implementing that feature, I suggested you to talk with the team, bite the bullet, and find time to refactor your code instead. From what you said, it feels like you can make a builder object that builds those model instead of relying on callback. You can add acceptance test for your current implementation (see that it’s currently working) then starts writing new code!
Others: I apologize that this sounds like a rubyonrails-talk answer other than rubyonrails-core, but I feel like it’s better for the code with lots of callback like this to be refactored to use a better approach than implementing a new functionality in Rails core that allows you to get out of jail free.
