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

Merged
merged 1 commit into from Jun 9, 2013

Conversation

Projects
None yet
8 participants
@wangjohn
Contributor

wangjohn commented Jun 8, 2013

Removed :automatic_inverse_of in favor of using the inverse_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 have options[: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.

@robin850

View changes

Show outdated Hide outdated activerecord/CHANGELOG.md
@jonleighton

This comment has been minimized.

Show comment
Hide comment
@jonleighton

jonleighton Jun 8, 2013

Member

@wangjohn regarding false vs nil, there's a difference between not having an :inverse_of option, and having a nil option. i.e. you could do options.include?(:inverse_of) && options[:inverse_of].nil?. Anyway, I don't really mind it being false actually, so let's leave it.

Member

jonleighton commented Jun 8, 2013

@wangjohn regarding false vs nil, there's a difference between not having an :inverse_of option, and having a nil option. i.e. you could do options.include?(:inverse_of) && options[:inverse_of].nil?. Anyway, I don't really mind it being false actually, so let's leave it.

@wangjohn

This comment has been minimized.

Show comment
Hide comment
@wangjohn

wangjohn Jun 8, 2013

Contributor

@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.

Contributor

wangjohn commented Jun 8, 2013

@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.

Getting rid of the +automatic_inverse_of: false+ option in associatio…
…ns in favor

of using +inverse_of: false+ option. Changing the documentation and
adding a CHANGELOG entry for the automatic inverse detection feature.

jonleighton added a commit that referenced this pull request Jun 9, 2013

Merge pull request #10886 from wangjohn/chnges_for_automatic_inverse_…
…associations

Documentation and cleanup of automatic discovery of inverse associations

@jonleighton jonleighton merged commit ae6e6d9 into rails:master Jun 9, 2013

#
# 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 &&

This comment has been minimized.

@egilburg

egilburg Jun 9, 2013

Contributor

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'.

@egilburg

egilburg Jun 9, 2013

Contributor

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'.

This comment has been minimized.

@Victorcorcos

Victorcorcos Aug 15, 2018

@egilburg Very interesting line of reasoning.

@Victorcorcos

Victorcorcos Aug 15, 2018

@egilburg Very interesting line of reasoning.

@lassebunk

This comment has been minimized.

Show comment
Hide comment
@lassebunk

lassebunk commented Dec 20, 2013

@egilburg 👍

@stevenharman stevenharman referenced this pull request Feb 19, 2014

Closed

Refactoring #75

@duduribeiro

This comment has been minimized.

Show comment
Hide comment
@duduribeiro

duduribeiro commented Jan 22, 2015

👍

@cyrilchampier

This comment has been minimized.

Show comment
Hide comment
@cyrilchampier

cyrilchampier Apr 10, 2018

sorry if this is not the right place to ask, but what would be a good reason to disable this behavior ?

cyrilchampier commented Apr 10, 2018

sorry if this is not the right place to ask, but what would be a good reason to disable this behavior ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment