GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
21eadc1 forced ActiveRecord::Base# and #= to use the default implementations of #read_attribute and #write_attribute respectively; if one of the latter methods is redefined, or wrapped with alias_method_chain, its alias will retain the default behaviour.
I don't think this change in semantics was intentional, so I've added tests for the expected behaviour and reverted 21eadc1 to make them pass.
Test ActiveRecord::Base#= as well as #write_attribute
Test that # and #= keep working when #read_attribute and #write_a…
…ttribute are overridden
Revert "Base# and Base#= are aliases so implement them as aliases…
This reverts commit 21eadc1.
This gets a +1 from me since 21eadc1 will break any gems/plugins that hook into read/write_attribute via alias_method_chain or even if they include a module into AR::Base and call super.
Merge pull request #4408 from tomstuart/read-and-write-attribute-aliases
# and #= are no longer interchangeable with #read_attribute and #write_attribute
Would you also accept backports to 3-1-stable and 3-2-stable?
@tomstuart I've backported it to 3-2-stable, please provide a pull request for 3-1-stable, thanks!!!
Huh, why hasn't this worked?
It is good to add a separate paragraph in the commit message with a rationale for the archives.
@fsvehla what didn't work?
It was reverted in dcebe7f
@fsvehla Ahhh, read the description of this pull request :)
@Spar Oh, yes, I get it now, thanks. Ruby does alias the method at the time when alias_method is executed, which is cool, and non-obvious.