undefined | Better HN

0 pointskarmakaze10mo ago0 comments

ActiveRecord may be both the best and worst part of Rails. Currently the largest scaling problem that I'm facing is with all the before_* and after_* callbacks which run per model record rather than a batch of changed records. This is an N+1 query landmine field for which ActiveRecord offers no solutions.

0 comments

benblue10mo ago

I agree that ActiveRecord isn't particularly opinionated about how to deal with updates to batches of records, but there are multiple ways of approaching this and AR won't get in your way.

upsert_all[1] is available to update a batch of records in a single write that does not invoke model callbacks.

activerecord-import[2] is also very nice gem that provides a great api for working with batches of records.

It can be as simple as extracting your callback logic and a method (def self.batch_update) and running your callback logic after the upsert.

[1] https://api.rubyonrails.org/classes/ActiveRecord/Relation.ht... [2] https://github.com/zdennis/activerecord-import

karmakazeOP10mo ago

By upsert_all not invoking model callbacks, it's admitting that the ActiveRecord approach doesn't scale.

"It can be as simple as extracting your callback..." Isn't this the kind of repetitive thing a framework should be doing on your behalf?

To be fair, ActiveRecord isn't a fault Rails invented. Apparently it's from one of Martin Fowler's many writings where each model instance manages its own storage. Even Fowler seems to say that the DataMapper approach is better to separate concerns in complex scenarios.

makeitdouble10mo ago

TBF no framework will do everything perfectly, and having clean escape hatches is pretty good in itself.

Even outside of batch processing, there will usually be a few queries that absolutely benefit from being rewritten in a lower layer of the ORM or even plain SQL. It's just a fact of life.

j / k navigate · click thread line to collapse