diff options
author | Xavier Noria <fxn@hashref.com> | 2014-06-07 13:04:40 +0200 |
---|---|---|
committer | Xavier Noria <fxn@hashref.com> | 2014-06-07 13:19:16 +0200 |
commit | 1ecada20d163ec1a3b0a3b6b51922da1dd7f089e (patch) | |
tree | cdede81a976ab194a53c32b38ba60338e4a17f95 /railties/test/engine_test.rb | |
parent | a39c88b5c9ddaf7df6768db0171846a5db1402fd (diff) | |
download | rails-1ecada20d163ec1a3b0a3b6b51922da1dd7f089e.tar.gz rails-1ecada20d163ec1a3b0a3b6b51922da1dd7f089e.tar.bz2 rails-1ecada20d163ec1a3b0a3b6b51922da1dd7f089e.zip |
Revert "Convert StrongParameters cache to a hash. This fixes an unbounded"
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.
Diffstat (limited to 'railties/test/engine_test.rb')
0 files changed, 0 insertions, 0 deletions