Hacker News new | ask | show | jobs
by dasil003 5757 days ago
He's not talking about eager loading associations. It's AR 3.0 backed by arel that allows ALL queries to be lazily loaded, as in, they are declared in the controller cleanly, but they only run in the view (and furthermore they only run if the view needs them).

Including assocations is an orthogonal issue. As far as I know they get the same benefit out of the box in Rails 3. For example, I think you can say:

@posts = Post.where(:published => true).include(:comments)

And it will still load it all eagerly, but it won't do it until you actually iterate over @posts.
1 comments
aaronblohowiak 5757 days ago
Ah, yes. I see what you are saying now. I was unaware that the abstract relational algebra was also able to defer joins. That is really an impressive bit of kit.

While this does satisfy the objection to association loading, you still have the general problem of delaying the flushing until after all controller processing has completed. for nontrivial applications, this may indeed take quite some time (talking with disparate backends for a SOA, for example.)

link
dasil003 5757 days ago
Well what would you prefer? A complete re-architecture of Rails to support SOAs? Declaring head and body renders separately? They did the hard work for ActiveRecord. Most Rails apps still use ActiveRecord and have a relatively straightforward architecture. If you want the same benefit for your SOA architecture, it's not that hard, just build a middleware layer that defers the queries like arel does. Even better, follow the facebook approach, render a page shell and load the content via AJAX. That will ultimately get you the best performance by far, allowing faster response times, piecemeal loading, maximal offloading of processing to the client side, and opens up interesting avenues for caching possibilities.
link
aaronblohowiak 5757 days ago
The ability (though of course not the requirement) to declare head and body renders separately would allow you to return the header before your processing, regardless of wether that processing is more intensive in the controller or the main body view.

Deferring only works if having a stub of a request is sufficient to proceed to the next step in the execution path. Unless you are going to implement your own conditionals (which, admittedly, is doable in ruby,) then you are going to force the evaluation of the request as soon as you want to use it to make a decision.

link