aboutsummaryrefslogtreecommitdiffstats
path: root/railties/test/engine_test.rb
diff options
context:
space:
mode:
authorXavier Noria <fxn@hashref.com>2014-06-07 13:04:40 +0200
committerXavier Noria <fxn@hashref.com>2014-06-07 13:19:16 +0200
commit1ecada20d163ec1a3b0a3b6b51922da1dd7f089e (patch)
treecdede81a976ab194a53c32b38ba60338e4a17f95 /railties/test/engine_test.rb
parenta39c88b5c9ddaf7df6768db0171846a5db1402fd (diff)
downloadrails-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