The main use case behind this addition seems to be saving lots of records whose attributes didn't change, where each attempted update would execute empty BEGIN/COMMIT statements (even though no UPDATE was issued), which didn't perform well.
This kind of bothers me. Isn't it something a developer should take care of, knowing the tradeoffs of the framework? record.save if record.changed? doesn't sound like a workaround for me but a proper programming approach to the problem of saving many objects.
Thanks! Yes, that shouldn't be difficult to do, but I suppose Active Record wants to prevent you from running into that performance problem to begin with. Personally, with Active Record it wouldn't come to my mind to add if record.changed?, because I assume record.save will not do anything if no columns changed. But instead of making ActiveRecord::Base#save not open a transaction in this case, which would avoid that problem, it was somehow better to implement lazy transactions? 🤷♂️
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article, as usual!
This kind of bothers me. Isn't it something a developer should take care of, knowing the tradeoffs of the framework?
record.save if record.changed?
doesn't sound like a workaround for me but a proper programming approach to the problem of saving many objects.Thanks! Yes, that shouldn't be difficult to do, but I suppose Active Record wants to prevent you from running into that performance problem to begin with. Personally, with Active Record it wouldn't come to my mind to add
if record.changed?
, because I assumerecord.save
will not do anything if no columns changed. But instead of makingActiveRecord::Base#save
not open a transaction in this case, which would avoid that problem, it was somehow better to implement lazy transactions? 🤷♂️