Documentation and cleanup of automatic discovery of inverse associations - #10886
Conversation
There was a problem hiding this comment.
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.
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
There was a problem hiding this comment.
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.
@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
8 participants
Removed
:automatic_inverse_ofin favor of using theinverse_of: falseto 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: nilto 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] = trueto use automatic associations doesn't make sense because at that point, the user can make the extra couple characters and type in the inverse.