shouldProxy: experiences?

Hi,

I played with this setting in 1:1 and 1:N mappings, and the only difference I found was WHEN the materialization happened.

fixUp

   wheels := wheels collect: [:each | each fixUp. each yourSelf].

   windshield := windshield yourSelf.

Esteban,

skimming over some code, my impression was that shouldProxy: false would be translated to alsoFetch: es when you read objects. My understanding was that shouldProxy: is the way of telling the descriptor to always fetch those other objects as well by joining instead of proxying.

Ex: If I do read all cars with all their wheels, I'd like this to be one statement instead of 1 statement for all the cars and once I iterate over the list of cars and their wheels for single statements, each for one wheel's proxy.

If that is not the case, I understand that shouldProxy: is not what I should do.

Maybe I need to think about using Query objects like you showed it here. This, however is not easy if your model cantains several places that could need a little boosting for this kind of situation...

So thanks for sharing.

Joachim



Am Donnerstag, 11. September 2014 22:56:49 UTC+2 schrieb Esteban A. Maringolo:

I played with this setting in 1:1 and 1:N mappings, and the only difference I found was WHEN the materialization happened.

The only thing I found to avoid roundtrips to the database was the use of #alsoFetch:, that causes huge speedups.

q := Query readManyOf: Car.

q alsoFetch: [:each | each wheels asOuterJoin].

q executeIn: session

The outer is to avoid an INNER JOIN which would remove items from the "1-side" of your relations.

In this example, if you remove #asOuterJoin, you won't get cars with no wheels in your result. 

Regards.

El viernes, 5 de septiembre de 2014 11:02:16 UTC-3, jtuchel escribió:

Hi,

I am looking for some experiences with using shouldProxy: on a OneToManyMapping.

My understanding is that a relationship with shouldProxy: false will not materialize Proxy for the collection of dependent objects but always build a full collection. In my model, the collection has a maximum size of 3, so I am not facing any problems with large collections here.

Does anybody have experience with this?

Did the use of shouldProxy: false speed anything up?

In my model, the relationship can be navigated from both directions and frequently is, so in order to speed things up, I'd like to use shouldProxy: false on both ends of the relationship. Has anybody done this before? Also, in my model the object on the 1-end of the relationship is not worth much without its n-ended counterparts. But the objects on the n-end of the relationship are connected to most of the outside of the "combined thing". So most objects come to this "combined thing" vie the n-end of the relationship. 

Think of it like this: 

A car has 1..n wheels. So if you load a car from the DB, you also always want the wheels, not their proxies. Most relationships to the car, are through the wheels (I can't think of  a good explanation for this in context of a car, but ...), so most of the times, if you want to access a car, you access one of its wheels first.

Does shouldProxy: help speed things up in this scenario?

Joachim

Hi Alan.

fixUp

   wheels := wheels collect: [:each | each fixUp. each yourSelf].

   windshield := windshield yourSelf.

Note: #yourSelf is a method Glorp defines because at least in VisualAge #yourself was inlined. If your dialect doesn't do that, you might be able to use normal #yourself.

I have a vague memory that shouldProxy: false might get you into trouble on a sufficiently complex circular relationship, though again I'm not certain. For simple ones I think it ought to handle it fine.  

Hmm. In my case it is just a car pointing to a few wheels, each of which points back to the car. So no complex circular relationship, the simplest possible.

Thinking through the whole thing, I guess I am asking for the wrong thing anyways - even if shouldProxy: false could reduce reading a car and its wheels to one single select, the most common situation of navigation from any object to the car through one of its wheels would profit much less, because I'd first have to ask the db for the wheel and then for the car with all its wheels. I'd still be down to 2 statements from up to five, but if I don't need the other three wheels for the specific operation, there is no speedup. It would even burn a few extra cycles for materializing the three unneeded wheels.

Oh my, simple things can be complicated. And somehow, I think this kind of problem is not really an ORM-exclusive problem domain.

Joachim