shouldProxy: experiences?

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

shouldProxy: experiences?

jtuchel
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

--
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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: shouldProxy: experiences?

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

--
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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: shouldProxy: experiences?

Alan Knight-2
What Estaban said. I believe that if you do the alsoFetch: it will also not put a proxy there, so that should address both retrieving the data and navigating the relationship, though you should probably verify that. But it probably wouldn't, for example, avoid a proxy on the backward relationship. So if reading a wheel alsoFetches the car, that doesn't mean the car's list of wheels isn't proxied. Or vice versa. You could also consider writing a fixup method, which is ugly, but might help e.g.

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.  



On Thu Sep 11 2014 at 1:56:50 PM Esteban A. Maringolo <[hidden email]> wrote:
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

--
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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: shouldProxy: experiences?

jtuchel
In reply to this post by Esteban A. Maringolo
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

--
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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: shouldProxy: experiences?

jtuchel
In reply to this post by Alan Knight-2
Hi Alan.


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


Sure. But this still is four selects for the wheels, right? So no speedup, just an up-front investment in cycles.

 
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.


This brings me to one of my favorite topics: ifNil:  and Proxies in Glorp ;-). But that is another story, and may not be solvable at all.
 
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


--
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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: shouldProxy: experiences?

Alan Knight-2


On 11 September 2014 22:41, jtuchel <[hidden email]> wrote:
Hi Alan.


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


Sure. But this still is four selects for the wheels, right? So no speedup, just an up-front investment in cycles.

If you've done an alsoFetch: of the wheels, then it will have been done in the original select. Which will be slower, because it's querying more, but still probably much faster than multiple queries.
 

 
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.


This brings me to one of my favorite topics: ifNil:  and Proxies in Glorp ;-). But that is another story, and may not be solvable at all.
 
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.

AlsoFetch: and filtered reads can be very useful for these kinds of cases, but they also take care to be applied correctly for your usage patterns. And it all gets much worse if you worry about other people modifying the car while you're looking at it, invalidating your pre-fetched data.  After all, there are only two hard problems in computer science - naming and cache invalidation.  Naming, cache invalidation, and off by one errors. Wait, I'll come in again.

 

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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
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 http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Loading...