Smalltalk › Frameworks & Tools › GLORP

#alsoFetch: limitations?

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 4 messages Options
Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
♦
♦
|

#alsoFetch: limitations?

Esteban A. Maringolo
What are the limitations of using #alsoFetch:?

If I use alsoFetch: in the following query, the events collection of the read class (GptRouteItem) only returns zero or one item, instead of 0..N.

| query  |
query := Query read: GptRouteItem where: [ :each | each owner date >= startDate AND: [ each owner date <= endDate ] ].
query shouldRefresh: true.
query orderBy: [ :each | each owner date ].
query alsoFetch: [ :each | each owner ].
query alsoFetch: [ :each | each justification asOuterJoin  ].
query alsoFetch: [ :each | each store ].
query alsoFetch: [ :each | each events asOuterJoin ]

If I remove the last line, the #events collection gets proxied and once materialized has the right number of elements.

Why is this so?
Is there some limitation of the relations it can bring? OneToOneMappings only?

Regards!

--
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.
Tom Robinson
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: #alsoFetch: limitations?

Tom Robinson
Esteban,

I'm not sure why you're getting only one item, but you should be aware that making a query in this way could bring back way more data than you expect. I believe that an SQL query written like this will bring back one row for each justification for each owner + one event row for each event for each justification + owner.  This means, if you have:

    1 owner
    3 justifications
    6 events

You would get back 18 rows...Needless to say, Glorp would throw away duplicate objects, but depending on the situation, this might put a higher memory and processor load on your server than you expect.

I think that getting the events using a filtered read in a second query might be better, but Alan would know better than I on that subject.


On 6/17/2014 4:52 PM, Esteban A. Maringolo wrote:
What are the limitations of using #alsoFetch:?

If I use alsoFetch: in the following query, the events collection of the read class (GptRouteItem) only returns zero or one item, instead of 0..N.

| query  |
query := Query read: GptRouteItem where: [ :each | each owner date >= startDate AND: [ each owner date <= endDate ] ].
query shouldRefresh: true.
query orderBy: [ :each | each owner date ].
query alsoFetch: [ :each | each owner ].
query alsoFetch: [ :each | each justification asOuterJoin  ].
query alsoFetch: [ :each | each store ].
query alsoFetch: [ :each | each events asOuterJoin ]

If I remove the last line, the #events collection gets proxied and once materialized has the right number of elements.

Why is this so?
Is there some limitation of the relations it can bring? OneToOneMappings only?

Regards!
--
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.
Alan Knight
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: #alsoFetch: limitations?

Alan Knight
Yes, what Tom said.  There shouldn't be any limitations on how many things it can bring back, but it does become exponentially large in the amount of data it retrieves.

It's also possible there's a bug in the way it de-duplicates the data that only shows up if you have a lot of things.

I think a filtered read for the events would do better. If it's a long chain then I think the filtered read might just re-do the whole query, but if it's different things all hanging off the route item, I think it should work well.

On Wed Jun 18 2014 at 2:42:18 PM, Tom Robinson <[hidden email]> wrote:
Esteban,

I'm not sure why you're getting only one item, but you should be aware that making a query in this way could bring back way more data than you expect. I believe that an SQL query written like this will bring back one row for each justification for each owner + one event row for each event for each justification + owner.  This means, if you have:

    1 owner
    3 justifications
    6 events

You would get back 18 rows...Needless to say, Glorp would throw away duplicate objects, but depending on the situation, this might put a higher memory and processor load on your server than you expect.

I think that getting the events using a filtered read in a second query might be better, but Alan would know better than I on that subject.



On 6/17/2014 4:52 PM, Esteban A. Maringolo wrote:
What are the limitations of using #alsoFetch:?

If I use alsoFetch: in the following query, the events collection of the read class (GptRouteItem) only returns zero or one item, instead of 0..N.

| query  |
query := Query read: GptRouteItem where: [ :each | each owner date >= startDate AND: [ each owner date <= endDate ] ].
query shouldRefresh: true.
query orderBy: [ :each | each owner date ].
query alsoFetch: [ :each | each owner ].
query alsoFetch: [ :each | each justification asOuterJoin  ].
query alsoFetch: [ :each | each store ].
query alsoFetch: [ :each | each events asOuterJoin ]

If I remove the last line, the #events collection gets proxied and once materialized has the right number of elements.

Why is this so?
Is there some limitation of the relations it can bring? OneToOneMappings only?

Regards!
--
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.

--
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.
Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: #alsoFetch: limitations?

Esteban A. Maringolo
In reply to this post by Tom Robinson
Why would it cause a cardinal multiplication?

I if execute the generated SQL query it properly brings back the right amount of rows. 
With the joined columns repeated, but that is expected, I guess.

I mean, if I have:
Routeitem: t1,
query alsoFetch: [ :each | each owner ]. "t2"
query alsoFetch: [ :each | each justification asOuterJoin  ]."t3"
query alsoFetch: [ :each | each store ]. "t4"
query alsoFetch: [ :each | each events asOuterJoin ] "t5"

assuming a cardinality of:
t1: 10
t2: 1
t3: 3
t4: 5
t5: 6 (per each element of t1)

If I remove the last #alsoFetch (t5) it properly brings back 10 rows (with t2, t3, t4 columns repeated alongside).

If I add the latest join, it only returns one row, when I would expect it to bring back 6x10 (t1 x t5).

The only difference I find is #events is a ToManyRelation, whereas the others are OneToOne.


Anyhow, what is a Filtered Read?
And what is Tracing?, btw. :)


Thank you!

--
Esteban.


El miércoles, 18 de junio de 2014 18:42:18 UTC-3, Tom Robinson escribió:
Esteban,

I'm not sure why you're getting only one item, but you should be aware that making a query in this way could bring back way more data than you expect. I believe that an SQL query written like this will bring back one row for each justification for each owner + one event row for each event for each justification + owner.  This means, if you have:

    1 owner
    3 justifications
    6 events

You would get back 18 rows...Needless to say, Glorp would throw away duplicate objects, but depending on the situation, this might put a higher memory and processor load on your server than you expect.

I think that getting the events using a filtered read in a second query might be better, but Alan would know better than I on that subject.


On 6/17/2014 4:52 PM, Esteban A. Maringolo wrote:
What are the limitations of using #alsoFetch:?

If I use alsoFetch: in the following query, the events collection of the read class (GptRouteItem) only returns zero or one item, instead of 0..N.

| query  |
query := Query read: GptRouteItem where: [ :each | each owner date >= startDate AND: [ each owner date <= endDate ] ].
query shouldRefresh: true.
query orderBy: [ :each | each owner date ].
query alsoFetch: [ :each | each owner ].
query alsoFetch: [ :each | each justification asOuterJoin  ].
query alsoFetch: [ :each | each store ].
query alsoFetch: [ :each | each events asOuterJoin ]

If I remove the last line, the #events collection gets proxied and once materialized has the right number of elements.

Why is this so?
Is there some limitation of the relations it can bring? OneToOneMappings only?


--
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.
Free forum by Nabble Edit this page