alsoFetch: is really a perfrmance booster. I am currently going through some of our more complex queries in our application to see whether I can replace them with expressions that use alsoFetch: (which clearly is something else than whether *they can be replaced* by such expressions ;-) ).
I also took a look at shouldProxy:, which I was hoping would also form joins and thus make things a lot faster. My first experiments, however, seem to imply that shouldProxy: does not join tables.
So if I have a 1:n relationship between cars and their wheels, mapping the car-wheel relationship with shouldProxy: false, the result will be no proxies for the #wheels collections and also the wheels will be materialized after a car ist read. So far, that is what I'd expect.
What I wasn't expecting that reading hundreds of cars still issues a select for each car's wheels individually. So it seems shouldProxy does not join. I was hoping that reading all cars with their wheels using shouldProxy would issue only one joined select, just like a Query does when I use alsoFetch: [:eachCar| eachCar wheels asOuterJoin].
Is this intended behavior or am I missing something? If it is intended, why?
And is there some other way to make Glorp always read such objects using a join?