Not sure what's causing them suddenly, but it seems unlikely there's
much we can do about it. For the small amount of coverage this
particular job gains us, it's hurting us more, by making CI failures
unremarkable.
The definition of `write_attribute` in dirty checking ultimately leads
to the columns calling `type_cast` on the value to perform the
comparison. However, this is a potentially expensive computation that we
cache when it occurs in `read_attribute`. The only case that we need the
non-type-cast form is for numeric, so we pass that through as well
(something I'm looking to remove in the future).
This also reduces the number of places that manually access various
stages in an attribute's type casting lifecycle, which will aid in one
of the larger refactorings that I'm working on.
Reduces the number of places that care about the internals of how we
store and type cast attributes. We do not need to go through the
dup/freeze dance, as you couldn't have saved a frozen new record anyway,
and that is the only time we would end up modifying the frozen hash.
There is no way to have an instance of an Active Record model where
`has_attribute?(self.class.primary_key)` returns false. The record is
always initialized in such a way that `@raw_attributes` will have an id
key with nil for the value.
We need to decorate the types lazily. This is extracted to a separate
API, as there are other refactorings that will be able to make use of
it, and to allow unit testing the finer points more granularly.
We cannot cache keys because arrays are mutable. We rather want to cache
the arrays. This behaviour is tailor-made for the usage pattern strongs
params is designed for.
In a forthcoming commit I am going to add a test that covers why we need
to cache by value.
Every strong params instance has a live span of a request, the cache goes
away with the object. Since strong params have such a concrete intention,
it would be interesting to see if there are actually any real-world use
cases that are an actual leak, one that practically may matter.
I am not convinced that the theoretical leak has any practical consequences,
but if it can be shown there are, then I believe we should either get rid of
the cache (which is an optimization), or else wipe it in the mutating API.
This reverts commit e63be2769c039e4e9ada523a8497ce3206cc8a9b.
This reverts commit be1db9946616a4005bb7be45656cc0f84d75d915, reversing
changes made to 6680ee9427ae2639e404cd3b9538f54e136057c6.
Reason: This changed a behavior where numeric attributes when receiving
blank values didn't change its value.
