As others have said, load is the method you’re looking for. to_a calls load, which is why it does what you’re looking for. Nate Berkopec has a really nice blog post about this. Though it seems if there’s a blog post needed to help explain it, perhaps the docs are lacking?
Thanks @natematykiewicz. Yep, as with some other things with Active Record, the most popular resource isn’t the Rails documentation, but rather a blog post. That indicates that the documentation is lacking.
It makes sense that to_a calls load, but that tells me that to_a should be named differently. Needing to understand that to_a actually runs a db query means that the API isn’t explicit or intuitive. It means that the method needs a new name. At least to me.
@mstrom81 I see this as a documentation issue rather than a naming issue, but you clearly feel strongly about this and I’d like to understand your perspective better.
My understanding of the scope chaining API is that it defers running queries until the “last responsible moment,” when people switch from modifying what data the query returns to performing actions on that data. Because a query result is a collection of items, the most natural API for performing actions on objects hydrated from that dataset is the Enumerable API. So whenever an Enumerable method (like to_a, but also like each or map) is called, then load is called as part of the process.
It sounds like you’re saying that because some developers you’ve worked with don’t have a good mental model of this system, they’ve learned to rely on to_a as a “cowpath” style solution. It sounds like you believe, based on that, that to_a ought to be renamed to something that reflects these developers’ usage of it.
My perspective is: to_a is a method on Enumerable, and having Relation and Association objects duck type as Enumerable is important to their usability. So I don’t believe that “renaming” to_a is desirable, or even possible. While I do believe in paving cowpaths, I think the consequences of trying to pave this one would have a lot of unpleasant ripple effects, so I’d rather solve the problem with better documentation.
It’s also possible that you’re arguing that ActiveRecord shouldn’t automatically run queries, but should make developers call load explicitly. If that’s your perspective, I strongly disagree. While I think something like detach might be useful in some circumstances (and am really excited by a similar 6.1 feature: Add `strict_loading` mode to optionally prevent lazy loading by eileencodes · Pull Request #37400 · rails/rails · GitHub), I feel that making developers make a “to load or not to load” decision whenever they write a scope would tend to discourage people from writing small, composable scope methods. There would also be backwards compatibility issues with that approach.
Anyway, it’s possible that I’m not understanding your perspective here, so I would like to hear more about it. It’s just that right now, I think that improved documentation is probably the best fix for the situation as I understand it.
1 Like
@Betsy_Haibel Thanks for clarifying.
I believe that Active Record should automatically run queries. I don’t have any issues with that. I agree with the to_a being a cowpath solution. I totally agree that improving the documentation is the best path forward as well.
I work with plenty of developers, myself included, who worked with Rails for years without fully understanding the lazy evaluation concept. When you run into an issue with it for the first time, to_a ends up being a bit confusing, and perhaps that’s because the documentation isn’t out there explaining it. Or maybe it is and I just haven’t found it.