Hi, I notice ActiveSupport::Cache implementations behave differently when cache key is nil. cache_key = nil Rails.cache.write(cache_key, ''value'') Rails.cache.read(cache_key) For example, FileStore raises a file system error "No such file or directory" when calling write() with nil cache key. This error does not communicate what actually went wrong (i.e. cache key cannot be nil/empty). It''s better if a descriptive exception is raised. Anyway, I''m curious what should be the expected behavior when cache key is nil? And whether the expected behavior should be specified in ActiveSupport::Cache or in its implementation? fyi, more details and failing tests are available: https://github.com/rails/rails/pull/11009 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
T.J. Schuck
2013-Jun-25 14:24 UTC
Re: How should ActiveSupport::Cache handle nil cache key?
From the table in your pull request, the MemCacheStore seems to be the one I''d expect from all the options, i.e. writing or reading a nil key raises "ArgumentError: key cannot be blank". Considering the docs even go as far as to say MemCacheStore is "currently the most popular cache store for production websites" and its current implementation is the most "breaking", I think it makes sense to mirror its behavior for the more dev environment oriented options. On Sat, Jun 22, 2013 at 4:28 AM, Huiming Teo <teohuiming@gmail.com> wrote:> Hi, I notice ActiveSupport::Cache implementations behave differently when > cache key is nil. > > cache_key = nil > Rails.cache.write(cache_key, ''value'') > Rails.cache.read(cache_key) > > For example, FileStore raises a file system error "No such file or > directory" when calling write() with nil cache key. This error does not > communicate what actually went wrong (i.e. cache key cannot be > nil/empty). It''s better if a descriptive exception is raised. > Anyway, I''m curious what should be the expected behavior when cache key > is nil? And whether the expected behavior should be specified in > ActiveSupport::Cache or in its implementation? > > fyi, more details and failing tests are available: > https://github.com/rails/rails/pull/11009 > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscribe@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Teo Hui Ming
2013-Jun-25 14:40 UTC
Re: How should ActiveSupport::Cache handle nil cache key?
Should we enforce the "no blank key" behavior in each implementation, or enforce it in the base class i.e. ActiveSupport::Cache? On Tue, Jun 25, 2013 at 10:24 PM, T.J. Schuck <tj@getharvest.com> wrote:> From the table in your pull request, the MemCacheStore seems to be the one > I''d expect from all the options, i.e. writing or reading a nil key raises > "ArgumentError: key cannot be blank". > > Considering the docs even go as far as to say MemCacheStore is "currently > the most popular cache store for production websites" and its current > implementation is the most "breaking", I think it makes sense to mirror its > behavior for the more dev environment oriented options. > > > On Sat, Jun 22, 2013 at 4:28 AM, Huiming Teo <teohuiming@gmail.com> wrote: >> >> Hi, I notice ActiveSupport::Cache implementations behave differently when >> cache key is nil. >> >> cache_key = nil >> Rails.cache.write(cache_key, ''value'') >> Rails.cache.read(cache_key) >> >> For example, FileStore raises a file system error "No such file or >> directory" when calling write() with nil cache key. This error does not >> communicate what actually went wrong (i.e. cache key cannot be nil/empty). >> It''s better if a descriptive exception is raised. >> >> Anyway, I''m curious what should be the expected behavior when cache key is >> nil? And whether the expected behavior should be specified in >> ActiveSupport::Cache or in its implementation? >> >> fyi, more details and failing tests are available: >> https://github.com/rails/rails/pull/11009 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rubyonrails-core+unsubscribe@googlegroups.com. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscribe@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. > >-- Huiming -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.