Do these two statements in The Rails 5 Way contradict each other?
up vote
2
down vote
favorite
I'm reading "The Rails 5 Way" now, and I've reached the section covering includes and joins. Up until now my understanding has been that includes is best-suited for eager-loading DB data into memory in order to avoid N+1 queries, while joins is more appropriate for doing simple filtering of a query result set based on associated tables, without actually accessing the attributes on those associated table rows:
1
includes(*associations)
Active Record has the capability to eliminate
“N+1” queries by letting you specify what associations to eager load
using theincludesmethod or option in your finders. Active Record
will load those relationships with the minimum number of queries
possible.
2
joins(expression)
joinsworks similarly to includes using an INNER
JOIN in the resulting SQL query. One of the key bits of knowledge to
understand about inner joins is they return only the set of records
that match the tables being joined. If a row on either side of the
join is missing its corresponding row on the other side, neither will
be returned in the result set.
However, on page 202 I see the following:
3
By far the most common usage of the
joinsmethod is to eager-fetch
data for associated objects in a single SELECT statement in order to
prevent so-called N+1 queries.
The usage described in quote #3 seems to be a closer fit with quote #1 than quote #2, i.e. it talks about the goal of reducing N+1 queries by eager-loading the data (which I know includes does by calling either eager_load or preload under the hood). To be honest, quote #3 doesn't appear to match #1 at all.
My question is- how can we reconcile these 3 quotes with each other? Or are they already in sync with each other and I'm simply missing something?
ruby-on-rails join rails-activerecord
asked Nov 10 at 23:01
Richie Thomas
1,17022036
add a comment |
up vote
2
down vote
favorite
I'm reading "The Rails 5 Way" now, and I've reached the section covering includes and joins. Up until now my understanding has been that includes is best-suited for eager-loading DB data into memory in order to avoid N+1 queries, while joins is more appropriate for doing simple filtering of a query result set based on associated tables, without actually accessing the attributes on those associated table rows:
1
includes(*associations)
Active Record has the capability to eliminate
“N+1” queries by letting you specify what associations to eager load
using theincludesmethod or option in your finders. Active Record
will load those relationships with the minimum number of queries
possible.
2
joins(expression)
joinsworks similarly to includes using an INNER
JOIN in the resulting SQL query. One of the key bits of knowledge to
understand about inner joins is they return only the set of records
that match the tables being joined. If a row on either side of the
join is missing its corresponding row on the other side, neither will
be returned in the result set.
However, on page 202 I see the following:
3
By far the most common usage of the
joinsmethod is to eager-fetch
data for associated objects in a single SELECT statement in order to
prevent so-called N+1 queries.
The usage described in quote #3 seems to be a closer fit with quote #1 than quote #2, i.e. it talks about the goal of reducing N+1 queries by eager-loading the data (which I know includes does by calling either eager_load or preload under the hood). To be honest, quote #3 doesn't appear to match #1 at all.
My question is- how can we reconcile these 3 quotes with each other? Or are they already in sync with each other and I'm simply missing something?
ruby-on-rails join rails-activerecord
asked Nov 10 at 23:01
Richie Thomas
1,17022036
4
Third quote is simply incorrect. Joins does not load associated records.
– Marcin Kołodziej
Nov 10 at 23:19
Eager vs lazy is orthogonal to includes vs join. Includes implicitly joins. If you do N+1 instead of avoiding it then obviously specify N query is "eager" in the informal sense that you evaluate it before the +1 query. The use of "eager" in quote 3 is wrong--they mean something like, simultaneously specify the N & (via the join) the +1. PS Please give a link.
– philipxy
Nov 10 at 23:21
i think we're confusing with eager-load vs eager-fetch in third quote. i'm sure the writer would have used eager-load as that term is more common; There has to be a reason why eager-fetch is used. Using joins, yes I do see how data for associated objects can be eager fetched. The sentence actually does say "how data for associated objects"; Building the associated objects through joins was probably out of scope for this quote.
– vee
Nov 11 at 3:29
Could be that the author is talking about selecting from the joined table without loading the association.Foo.select(“foos.*, bars.baz AS baz”).joins(:bar). This can be used with aggregates like count or average. But this is not actually that common.
– max
Nov 11 at 9:48
@philipxy- can you clarify what kind of link you mean? The 3 quotes are from a book, not from a page I can link to. I could link to the book's page on Amazon, if that will help, but I did mention the book's title already so I'm not sure how much added benefit that would be.
– Richie Thomas
Nov 11 at 18:27
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I'm reading "The Rails 5 Way" now, and I've reached the section covering includes and joins. Up until now my understanding has been that includes is best-suited for eager-loading DB data into memory in order to avoid N+1 queries, while joins is more appropriate for doing simple filtering of a query result set based on associated tables, without actually accessing the attributes on those associated table rows:
1
includes(*associations)
Active Record has the capability to eliminate
“N+1” queries by letting you specify what associations to eager load
using theincludesmethod or option in your finders. Active Record
will load those relationships with the minimum number of queries
possible.
2
joins(expression)
joinsworks similarly to includes using an INNER
JOIN in the resulting SQL query. One of the key bits of knowledge to
understand about inner joins is they return only the set of records
that match the tables being joined. If a row on either side of the
join is missing its corresponding row on the other side, neither will
be returned in the result set.
However, on page 202 I see the following:
3
By far the most common usage of the
joinsmethod is to eager-fetch
data for associated objects in a single SELECT statement in order to
prevent so-called N+1 queries.
The usage described in quote #3 seems to be a closer fit with quote #1 than quote #2, i.e. it talks about the goal of reducing N+1 queries by eager-loading the data (which I know includes does by calling either eager_load or preload under the hood). To be honest, quote #3 doesn't appear to match #1 at all.
My question is- how can we reconcile these 3 quotes with each other? Or are they already in sync with each other and I'm simply missing something?
ruby-on-rails join rails-activerecord
asked Nov 10 at 23:01
Richie Thomas
1,17022036
I'm reading "The Rails 5 Way" now, and I've reached the section covering includes and joins. Up until now my understanding has been that includes is best-suited for eager-loading DB data into memory in order to avoid N+1 queries, while joins is more appropriate for doing simple filtering of a query result set based on associated tables, without actually accessing the attributes on those associated table rows:
1
includes(*associations)
Active Record has the capability to eliminate
“N+1” queries by letting you specify what associations to eager load
using theincludesmethod or option in your finders. Active Record
will load those relationships with the minimum number of queries
possible.
2
joins(expression)
joinsworks similarly to includes using an INNER
JOIN in the resulting SQL query. One of the key bits of knowledge to
understand about inner joins is they return only the set of records
that match the tables being joined. If a row on either side of the
join is missing its corresponding row on the other side, neither will
be returned in the result set.
However, on page 202 I see the following:
3
By far the most common usage of the
joinsmethod is to eager-fetch
data for associated objects in a single SELECT statement in order to
prevent so-called N+1 queries.
The usage described in quote #3 seems to be a closer fit with quote #1 than quote #2, i.e. it talks about the goal of reducing N+1 queries by eager-loading the data (which I know includes does by calling either eager_load or preload under the hood). To be honest, quote #3 doesn't appear to match #1 at all.
My question is- how can we reconcile these 3 quotes with each other? Or are they already in sync with each other and I'm simply missing something?
ruby-on-rails join rails-activerecord
ruby-on-rails join rails-activerecord
asked Nov 10 at 23:01
Richie Thomas
1,17022036
asked Nov 10 at 23:01
Richie Thomas
1,17022036
edited Nov 11 at 18:23
asked Nov 10 at 23:01
Richie Thomas
1,17022036
asked Nov 10 at 23:01
Richie Thomas
1,17022036
asked Nov 10 at 23:01
Richie Thomas
1,17022036
1,17022036
4
Third quote is simply incorrect. Joins does not load associated records.
– Marcin Kołodziej
Nov 10 at 23:19
Eager vs lazy is orthogonal to includes vs join. Includes implicitly joins. If you do N+1 instead of avoiding it then obviously specify N query is "eager" in the informal sense that you evaluate it before the +1 query. The use of "eager" in quote 3 is wrong--they mean something like, simultaneously specify the N & (via the join) the +1. PS Please give a link.
– philipxy
Nov 10 at 23:21
i think we're confusing with eager-load vs eager-fetch in third quote. i'm sure the writer would have used eager-load as that term is more common; There has to be a reason why eager-fetch is used. Using joins, yes I do see how data for associated objects can be eager fetched. The sentence actually does say "how data for associated objects"; Building the associated objects through joins was probably out of scope for this quote.
– vee
Nov 11 at 3:29
Could be that the author is talking about selecting from the joined table without loading the association.Foo.select(“foos.*, bars.baz AS baz”).joins(:bar). This can be used with aggregates like count or average. But this is not actually that common.
– max
Nov 11 at 9:48
@philipxy- can you clarify what kind of link you mean? The 3 quotes are from a book, not from a page I can link to. I could link to the book's page on Amazon, if that will help, but I did mention the book's title already so I'm not sure how much added benefit that would be.
– Richie Thomas
Nov 11 at 18:27
add a comment |
4
Third quote is simply incorrect. Joins does not load associated records.
– Marcin Kołodziej
Nov 10 at 23:19
Eager vs lazy is orthogonal to includes vs join. Includes implicitly joins. If you do N+1 instead of avoiding it then obviously specify N query is "eager" in the informal sense that you evaluate it before the +1 query. The use of "eager" in quote 3 is wrong--they mean something like, simultaneously specify the N & (via the join) the +1. PS Please give a link.
– philipxy
Nov 10 at 23:21
i think we're confusing with eager-load vs eager-fetch in third quote. i'm sure the writer would have used eager-load as that term is more common; There has to be a reason why eager-fetch is used. Using joins, yes I do see how data for associated objects can be eager fetched. The sentence actually does say "how data for associated objects"; Building the associated objects through joins was probably out of scope for this quote.
– vee
Nov 11 at 3:29
Could be that the author is talking about selecting from the joined table without loading the association.Foo.select(“foos.*, bars.baz AS baz”).joins(:bar). This can be used with aggregates like count or average. But this is not actually that common.
– max
Nov 11 at 9:48
@philipxy- can you clarify what kind of link you mean? The 3 quotes are from a book, not from a page I can link to. I could link to the book's page on Amazon, if that will help, but I did mention the book's title already so I'm not sure how much added benefit that would be.
– Richie Thomas
Nov 11 at 18:27
4
4
Third quote is simply incorrect. Joins does not load associated records.
– Marcin Kołodziej
Nov 10 at 23:19
Third quote is simply incorrect. Joins does not load associated records.
– Marcin Kołodziej
Nov 10 at 23:19
Eager vs lazy is orthogonal to includes vs join. Includes implicitly joins. If you do N+1 instead of avoiding it then obviously specify N query is "eager" in the informal sense that you evaluate it before the +1 query. The use of "eager" in quote 3 is wrong--they mean something like, simultaneously specify the N & (via the join) the +1. PS Please give a link.
– philipxy
Nov 10 at 23:21
Eager vs lazy is orthogonal to includes vs join. Includes implicitly joins. If you do N+1 instead of avoiding it then obviously specify N query is "eager" in the informal sense that you evaluate it before the +1 query. The use of "eager" in quote 3 is wrong--they mean something like, simultaneously specify the N & (via the join) the +1. PS Please give a link.
– philipxy
Nov 10 at 23:21
i think we're confusing with eager-load vs eager-fetch in third quote. i'm sure the writer would have used eager-load as that term is more common; There has to be a reason why eager-fetch is used. Using joins, yes I do see how data for associated objects can be eager fetched. The sentence actually does say "how data for associated objects"; Building the associated objects through joins was probably out of scope for this quote.
– vee
Nov 11 at 3:29
i think we're confusing with eager-load vs eager-fetch in third quote. i'm sure the writer would have used eager-load as that term is more common; There has to be a reason why eager-fetch is used. Using joins, yes I do see how data for associated objects can be eager fetched. The sentence actually does say "how data for associated objects"; Building the associated objects through joins was probably out of scope for this quote.
– vee
Nov 11 at 3:29
Could be that the author is talking about selecting from the joined table without loading the association.
Foo.select(“foos.*, bars.baz AS baz”).joins(:bar). This can be used with aggregates like count or average. But this is not actually that common.– max
Nov 11 at 9:48
Could be that the author is talking about selecting from the joined table without loading the association.
Foo.select(“foos.*, bars.baz AS baz”).joins(:bar). This can be used with aggregates like count or average. But this is not actually that common.– max
Nov 11 at 9:48
@philipxy- can you clarify what kind of link you mean? The 3 quotes are from a book, not from a page I can link to. I could link to the book's page on Amazon, if that will help, but I did mention the book's title already so I'm not sure how much added benefit that would be.
– Richie Thomas
Nov 11 at 18:27
@philipxy- can you clarify what kind of link you mean? The 3 quotes are from a book, not from a page I can link to. I could link to the book's page on Amazon, if that will help, but I did mention the book's title already so I'm not sure how much added benefit that would be.
– Richie Thomas
Nov 11 at 18:27
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53244265%2fdo-these-two-statements-in-the-rails-5-way-contradict-each-other%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
Third quote is simply incorrect. Joins does not load associated records.
– Marcin Kołodziej
Nov 10 at 23:19
Eager vs lazy is orthogonal to includes vs join. Includes implicitly joins. If you do N+1 instead of avoiding it then obviously specify N query is "eager" in the informal sense that you evaluate it before the +1 query. The use of "eager" in quote 3 is wrong--they mean something like, simultaneously specify the N & (via the join) the +1. PS Please give a link.
– philipxy
Nov 10 at 23:21
i think we're confusing with eager-load vs eager-fetch in third quote. i'm sure the writer would have used eager-load as that term is more common; There has to be a reason why eager-fetch is used. Using joins, yes I do see how data for associated objects can be eager fetched. The sentence actually does say "how data for associated objects"; Building the associated objects through joins was probably out of scope for this quote.
– vee
Nov 11 at 3:29
Could be that the author is talking about selecting from the joined table without loading the association.
Foo.select(“foos.*, bars.baz AS baz”).joins(:bar). This can be used with aggregates like count or average. But this is not actually that common.– max
Nov 11 at 9:48
@philipxy- can you clarify what kind of link you mean? The 3 quotes are from a book, not from a page I can link to. I could link to the book's page on Amazon, if that will help, but I did mention the book's title already so I'm not sure how much added benefit that would be.
– Richie Thomas
Nov 11 at 18:27