-
Notifications
You must be signed in to change notification settings - Fork 21.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation and cleanup of automatic discovery of inverse associations #10886
Documentation and cleanup of automatic discovery of inverse associations #10886
Conversation
especially the ones with non-standard names. | ||
|
||
You can turn off the automatic detection of inverse associations by setting | ||
the <tt>:inverse_of</tt> option to <tt>false</tt> like so: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you use <tt>
elements there instead of backticks just like before? In my opinion, it's more readable with backticks. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this should be backticks because it's a Markdown file.
@wangjohn regarding false vs nil, there's a difference between not having an |
@jonleighton Ahh, thanks for the pointer, that does make sense. @robin850 Thank you for the comment, I've fixed the CHANGELOG entry to use backticks instead. |
…ns in favor of using +inverse_of: false+ option. Changing the documentation and adding a CHANGELOG entry for the automatic inverse detection feature.
…associations Documentation and cleanup of automatic discovery of inverse associations
# | ||
# Anything with a scope can additionally ruin our attempt at finding an | ||
# inverse, so we exclude reflections with scopes. | ||
def can_find_inverse_of_automatically?(reflection) | ||
reflection.options[:automatic_inverse_of] != false && | ||
reflection.options[:inverse_of] != false && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can do reflection.options.keys.include?(:inverse_of) && !reflection.options[:inverse_of]
so passing either explicit nil
or false
would work. I agree with original review that nil
is more intuitive since it makes the line semantics more declarative (e.g. as a Rails developer I say there is 'no' defined inverse, rather than explicitly saying 'do not run some process that sets it'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@egilburg Very interesting line of reasoning.
👍 |
sorry if this is not the right place to ask, but what would be a good reason to disable this behavior ? |
ActiveRecord has a performance optimisation which allows it to automatically detect the inverse of an association, i.e.: foo = Foo.find(1) # performs DB call foo.bar # performs DB call foo.bar.foo # no additional call! This feature was added in Rails 4.2 [1]. However, if you specify a foreign_key, this behaviour is skipped which means that the third expression above will make a DB call. Since the foreign_key is only necessary when it doesn't match the Rails' expectation (`{resource}_id`) we can just omit the option in those cases, which means lookups will sometimes be faster again. [1]: rails/rails#10886
ActiveRecord has a performance optimisation which allows it to automatically detect the inverse of an association, i.e.: foo = Foo.find(1) # performs DB call foo.bar # performs DB call foo.bar.foo # no additional call! This feature was added in Rails 4.2 [1]. However, if you specify a foreign_key, this behaviour is skipped which means that the third expression above will make a DB call. Since the foreign_key is only necessary when it doesn't match the Rails' expectation (`{resource}_id`) we can just omit the option in those cases, which means lookups will sometimes be faster again. [1]: rails/rails#10886
Removed
:automatic_inverse_of
in favor of using theinverse_of: false
to tell us whether we don't want to use automatic inverses. Changing the documentation and adding a CHANGELOG entry for the automatic inverse detection feature.@jonleighton I don't think it's actually possible to use
inverse_of: nil
to tell us to not automatically find inverse associations. This is because the feature would be completely useless, since by default, we haveoptions[:inverse_of] = nil
. This means, by default we do not use automatic inverse finding.Conversely, having the user specify
options[:inverse_of] = true
to use automatic associations doesn't make sense because at that point, the user can make the extra couple characters and type in the inverse.