Drop the setter methods cache in favour of respond_to? (see #472) #473
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_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 asrespond_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.