Fetching strategies in Grails documentation

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

Fetching strategies in Grails documentation

Vincent Frison-2
Hello,

In the section 6.3.4 of the official documentation, which speaks about" Eager and Lazy Fetching", it's written that using lazy:false (int the flights association of Airport) can avoid the N+1 queries issue. 

But IMHO that is not true, setting the association to eager doesn't solve the problem by itself. 

Eager/Lazy just mean *when* the association mut be loaded: 'eager' means that the association must be loaded instantly as 'lazy' means it will be loaded only when it will be required. But what could really avoid the N+1 problem is the *how* it must be loaded, not the *when*. By default the *how* is set to 'select' which means another SELECT SQL statement must be executed in order to fetch the associated entities. To avoid the N+1 problem the *how* must be changed to either 'join' or 'batch' or 'subselect' (apparently the last one is not possible in Grails).

I think the documentation should be corrected to avoid confusion altough it's not easy to explain Hibernate fetching strategies in a few lines...

In fact the used example deals with 3 entities: Airport, Flight and Location (it could be simpler with 2 entities only). If the flights association of Airport is set to eager, there are still N+1 queries to be executed in order to fetch relative locations ! The problem can be avoived by setting join:'fetch' on the location association of Flight.

I'm also confused with the next section about "Batch fetching". The batch mode is usefull when you load mulitple parent instances because associated entities can be fetched in one shoot for many parents (SELECT ... IN (multiple ParentIds)). But If you have only one parent entity, which is the case of the example, it doesn't make sense for me. 

Thanks, Vincent.




--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" 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].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/4545d1f9-dbdd-42bf-b137-de3c84f93e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Fetching strategies in Grails documentation

Graeme Rocher-2
Yes it seems there is some erroneous information regarding the different between fetchMode (select or join) and lazy (proxy or not). Please raise an issue and point out the errors of concern that you have found and we can improve on this.

Thanks
Graeme

On 27 Jan 2016, at 15:52, Vincent Frison <[hidden email]> wrote:

Hello,

In the section 6.3.4 of the official documentation, which speaks about" Eager and Lazy Fetching", it's written that using lazy:false (int the flights association of Airport) can avoid the N+1 queries issue. 

But IMHO that is not true, setting the association to eager doesn't solve the problem by itself. 

Eager/Lazy just mean *when* the association mut be loaded: 'eager' means that the association must be loaded instantly as 'lazy' means it will be loaded only when it will be required. But what could really avoid the N+1 problem is the *how* it must be loaded, not the *when*. By default the *how* is set to 'select' which means another SELECT SQL statement must be executed in order to fetch the associated entities. To avoid the N+1 problem the *how* must be changed to either 'join' or 'batch' or 'subselect' (apparently the last one is not possible in Grails).

I think the documentation should be corrected to avoid confusion altough it's not easy to explain Hibernate fetching strategies in a few lines...

In fact the used example deals with 3 entities: Airport, Flight and Location (it could be simpler with 2 entities only). If the flights association of Airport is set to eager, there are still N+1 queries to be executed in order to fetch relative locations ! The problem can be avoived by setting join:'fetch' on the location association of Flight.

I'm also confused with the next section about "Batch fetching". The batch mode is usefull when you load mulitple parent instances because associated entities can be fetched in one shoot for many parents (SELECT ... IN (multiple ParentIds)). But If you have only one parent entity, which is the case of the example, it doesn't make sense for me. 

Thanks, Vincent.





--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" 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].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/4545d1f9-dbdd-42bf-b137-de3c84f93e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" 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].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/8141B168-7DC6-4A15-97C9-4E930A757212%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Fetching strategies in Grails documentation

Vincent Frison-2
Ok I've created an issue in the grails-doc project: https://github.com/grails/grails-doc/issues/424

Thanks, Vincent.

2016-01-28 16:10 GMT+01:00 Graeme Rocher <[hidden email]>:
Yes it seems there is some erroneous information regarding the different between fetchMode (select or join) and lazy (proxy or not). Please raise an issue and point out the errors of concern that you have found and we can improve on this.

Thanks
Graeme

On 27 Jan 2016, at 15:52, Vincent Frison <[hidden email]> wrote:

Hello,

In the section 6.3.4 of the official documentation, which speaks about" Eager and Lazy Fetching", it's written that using lazy:false (int the flights association of Airport) can avoid the N+1 queries issue. 

But IMHO that is not true, setting the association to eager doesn't solve the problem by itself. 

Eager/Lazy just mean *when* the association mut be loaded: 'eager' means that the association must be loaded instantly as 'lazy' means it will be loaded only when it will be required. But what could really avoid the N+1 problem is the *how* it must be loaded, not the *when*. By default the *how* is set to 'select' which means another SELECT SQL statement must be executed in order to fetch the associated entities. To avoid the N+1 problem the *how* must be changed to either 'join' or 'batch' or 'subselect' (apparently the last one is not possible in Grails).

I think the documentation should be corrected to avoid confusion altough it's not easy to explain Hibernate fetching strategies in a few lines...

In fact the used example deals with 3 entities: Airport, Flight and Location (it could be simpler with 2 entities only). If the flights association of Airport is set to eager, there are still N+1 queries to be executed in order to fetch relative locations ! The problem can be avoived by setting join:'fetch' on the location association of Flight.

I'm also confused with the next section about "Batch fetching". The batch mode is usefull when you load mulitple parent instances because associated entities can be fetched in one shoot for many parents (SELECT ... IN (multiple ParentIds)). But If you have only one parent entity, which is the case of the example, it doesn't make sense for me. 

Thanks, Vincent.





--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" 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].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/4545d1f9-dbdd-42bf-b137-de3c84f93e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" 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].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/8141B168-7DC6-4A15-97C9-4E930A757212%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" 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].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/CAKB97E4wi6%2BoFG5VGDQQb5CFZRFV6UUQWX5%3DXxBEoxuQ%3DHTq2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.