Quantcast

alsoFetch: and shouldProxy:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

alsoFetch: and shouldProxy:

jtuchel
Hi

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?

Thx

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Loading...