Filling a Collection with alsoFetch: still materializes Proxies...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Filling a Collection with alsoFetch: still materializes Proxies...

jtuchel
Hi there,

I have this weird thing I don't understand. For a GUI component I issue a query like this (very simplified):

q := SimpleQuery read: Garage where: [:g| g cars anySatisfy: [:c| color = 'silver']].
q alsoFetch: [:g| g car wheels asOuterJoin].

myCarCollection := self session execute: q.

Obviously, I am talking about a OneToManyRelationship here.

So once this collection of cars is read from the database, it is displayed in a list to the user. IN the list I want to display whether the car has wheels or not.

Now to the "funny" effect. Each car will then issue an SQL statement like this whenever the getter #cars of a Garage is accessed:

SELECT t1.id, ...
FROM WHEEL WHERE CAR_ID = "the id of a car"

So it seems that even though my initial search/query joins the Garage, Car and Wheel table, the cars will hold a Proxy in their wheels inst var.

In our not so simple productive case, this means that some lists take a long time to render because it issues a few hundred SQL statements for data that has already been read in the first query.

I already tried tried #shouldProxy: false in the OneToManyMapping for the car's wheels attribute, but to no avail. Even adding the alsoFetch: to the Garage's #cars mapping doesn't avoid these extra SQLs. (and it may be a tricky optimization that strikes back whenever the wheels of cars in a garage aren't needed....)

Any ideas what I can do?


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 view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/04df8996-dc80-4be8-b034-c7ebf047532en%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Filling a Collection with alsoFetch: still materializes Proxies...

Thomas Brodt

Your query fetches Garages and you do an alsoFetch: of wheels, but not of the cars. Maybe you have a retrieve: [:g | g car] that isn't mentioned in the mail, that would change the query output to cars. If you add

q alsoFetch: [:g | g car "or cars?"]

to the query (not to the mapping) does this help?

So you should have

q := SimpleQuery read: Garage where: [:g| g cars anySatisfy: [:c| color = 'silver']].
q alsoFetch: [:g | g cars]
q alsoFetch: [:g | g car wheels asOuterJoin].

Thomas

porabo signature TB

Freundliche Grüsse
Thomas Brodt



porabo Consulting GmbH
Thomas Brodt, Diplom-Informatiker
Leiter Entwicklung

High-Tech-Center 1  •  Lohstampfestrasse 11  •  8274 Tägerwilen, Schweiz
<a href="tel:+410716772050">+41 (0) 71 677 20 50  •  [hidden email]  •  www.porabo.com
porabo signature TB Am 04.11.2020 um 08:09 schrieb jtuchel:
Hi there,

I have this weird thing I don't understand. For a GUI component I issue a query like this (very simplified):

q := SimpleQuery read: Garage where: [:g| g cars anySatisfy: [:c| color = 'silver']].
q alsoFetch: [:g| g car wheels asOuterJoin].

myCarCollection := self session execute: q.

Obviously, I am talking about a OneToManyRelationship here.

So once this collection of cars is read from the database, it is displayed in a list to the user. IN the list I want to display whether the car has wheels or not.

Now to the "funny" effect. Each car will then issue an SQL statement like this whenever the getter #cars of a Garage is accessed:

SELECT t1.id, ...
FROM WHEEL WHERE CAR_ID = "the id of a car"

So it seems that even though my initial search/query joins the Garage, Car and Wheel table, the cars will hold a Proxy in their wheels inst var.

In our not so simple productive case, this means that some lists take a long time to render because it issues a few hundred SQL statements for data that has already been read in the first query.

I already tried tried #shouldProxy: false in the OneToManyMapping for the car's wheels attribute, but to no avail. Even adding the alsoFetch: to the Garage's #cars mapping doesn't avoid these extra SQLs. (and it may be a tricky optimization that strikes back whenever the wheels of cars in a garage aren't needed....)

Any ideas what I can do?


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 view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/04df8996-dc80-4be8-b034-c7ebf047532en%40googlegroups.com.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/da9e8eac-5809-5a66-5129-c9bdb59bdf88%40porabo.com.
Reply | Threaded
Open this post in threaded view
|

Re: Filling a Collection with alsoFetch: still materializes Proxies...

jtuchel
Hi Thomas,

thanks for you suggestion. I tried

q := SimpleQuery read: Garage where: [:g| g cars anySatisfy: [:c| color = 'silver']].
q alsoFetch: [:g | g cars]
q alsoFetch: [:g | g cars wheels asOuterJoin].

but the list rendering still sends out a single select for the wheels of each car just milliseconds later.

This is strange, because I don't see this behaviour in other places where we use #alsoFetch: in Queries. It is a very efficient performance booster under (whatever different) circumstances.

Joachim






[hidden email] schrieb am Mittwoch, 4. November 2020 um 11:17:45 UTC+1:

Your query fetches Garages and you do an alsoFetch: of wheels, but not of the cars. Maybe you have a retrieve: [:g | g car] that isn't mentioned in the mail, that would change the query output to cars. If you add

q alsoFetch: [:g | g car "or cars?"]

to the query (not to the mapping) does this help?

So you should have

q := SimpleQuery read: Garage where: [:g| g cars anySatisfy: [:c| color = 'silver']].
q alsoFetch: [:g | g cars]
q alsoFetch: [:g | g car wheels asOuterJoin].

Thomas

Freundliche Grüsse
Thomas Brodt



porabo Consulting GmbH
Thomas Brodt, Diplom-Informatiker
Leiter Entwicklung

High-Tech-Center 1  •  Lohstampfestrasse 11  •  8274 Tägerwilen, Schweiz
<a href="tel:+410716772050" target="_blank" rel="nofollow">+41 (0) 71 677 20 50  •  [hidden email]  •  www.porabo.com
Am 04.11.2020 um 08:09 schrieb jtuchel:
Hi there,

I have this weird thing I don't understand. For a GUI component I issue a query like this (very simplified):

q := SimpleQuery read: Garage where: [:g| g cars anySatisfy: [:c| color = 'silver']].
q alsoFetch: [:g| g car wheels asOuterJoin].

myCarCollection := self session execute: q.

Obviously, I am talking about a OneToManyRelationship here.

So once this collection of cars is read from the database, it is displayed in a list to the user. IN the list I want to display whether the car has wheels or not.

Now to the "funny" effect. Each car will then issue an SQL statement like this whenever the getter #cars of a Garage is accessed:

SELECT t1.id, ...
FROM WHEEL WHERE CAR_ID = "the id of a car"

So it seems that even though my initial search/query joins the Garage, Car and Wheel table, the cars will hold a Proxy in their wheels inst var.

In our not so simple productive case, this means that some lists take a long time to render because it issues a few hundred SQL statements for data that has already been read in the first query.

I already tried tried #shouldProxy: false in the OneToManyMapping for the car's wheels attribute, but to no avail. Even adding the alsoFetch: to the Garage's #cars mapping doesn't avoid these extra SQLs. (and it may be a tricky optimization that strikes back whenever the wheels of cars in a garage aren't needed....)

Any ideas what I can do?


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 view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/04df8996-dc80-4be8-b034-c7ebf047532en%40googlegroups.com.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/43b19a39-42f1-43dd-8d4b-62b407686e12n%40googlegroups.com.