Drop the setter methods cache in favour of respond_to? (see #472)#473
Open
chewi wants to merge 1 commit intoremi:masterfrom
Open
Drop the setter methods cache in favour of respond_to? (see #472)#473chewi wants to merge 1 commit intoremi:masterfrom
chewi wants to merge 1 commit intoremi:masterfrom
Conversation
chewi
force-pushed
the
remove-setter-methods-cache
branch
from
d11b81b to
9a952e6
Compare
Contributor
Author
|
Rebased. I think this one is particularly important and it stands alone from my other remaining changes. |
The cache was not being updated when new attributes were added, causing very strange behaviour. Any previously unseen attributes passed to new with send_only_modified_attributes enabled would be missing from the request parameters. This is because change tracking is only effective for setter methods. Updating the cache turned out to be more expensive than not having a cache at all. Using respond_to? would be fastest but this breaks things as respond_to_missing? returns true for any assignment method. If method(:foo=).source_location returns nil then this may indicate that the method is missing but this is also true for methods in native code. A faster and more reliable approach is using a fiber-local variable to make respond_to_missing? return false while doing these checks. It's a tad ugly but it's the best I can come up with.
chewi
force-pushed
the
remove-setter-methods-cache
branch
from
9a952e6 to
0632835
Compare
Contributor
Author
|
I'm leaving the company soon and I'd like to get some (or all!) of these merged before I go. This one seems like a good start. |
Contributor
Author
|
One week to go. 😛 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The cache was not being updated when new attributes were added, causing very strange behaviour. Any previously unseen attributes passed to new with
send_only_modified_attributesenabled would be missing from the request parameters. This is because change tracking is only effective for setter methods.Updating the cache turned out to be more expensive than not having a cache at all. Using
respond_to?would be fastest but this breaks things asrespond_to_missing?returns true for any assignment method.If
method(:foo=).source_locationreturns nil then this may indicate that the method is missing but this is also true for methods in native code.A faster and more reliable approach is using a fiber-local variable to make
respond_to_missing?return false while doing these checks. It's a tad ugly but it's the best I can come up with.