I'm implementing caching on Heroku using Dalli and Memcachier, and when I get a cache hit it's adding a Symbol to the returned array (or hash, in a different example). This Symbol, :@new_record, has nothing that I know of to do with the results I'm returning, is inserted on different types of cache fetches, and I haven't been able to find someone else on SO/Google with this issue. A codebase-wide find returns no results for "new_record".
This addition has happened in two places where I've tried to add caching. I don't know how to prevent it from happening in the first place, but I dodge its effects in this particular use by checking the class of each record in the returned set, and not rendering a Supplier's profile if it's not a Supplier. This is an ugly solution, and I'd like to solve the problem at the source.
Please let me know if you have any additional questions / need me to post more information, and thanks for your help.
The method I'm using caching in:
#this will be slow, need to store it somewhere
def self.set_for_index(index_name)
guide = INDEX_HOLDER[index_name]
return false if guide.nil?
haves, have_nots, countries = guide[0], guide[1], guide[2]
holder = []
supplier_set = Rails.cache.fetch("set_for_index_#{index_name}", :expires_in => 24.hours) {
Supplier.find_each do |s|
if (
s.profile_visible and
(countries == [] or (s.address and countries.include?(s.address.country))) and
!(haves.map{ |h| s.has_tag?(Tag.find_by_name(h).id) }.include?(false)) and
!(have_nots.map{ |h| s.has_tag?(Tag.find_by_name(h).id) }.include?(true))
)
holder << s
end
end
holder
}
return supplier_set
end
I'm screening out the :@new_record right now using the last line of this code:
def self.visible_profiles_sorted(index_name)
profiles = Supplier.set_for_index(index_name)
answer = {}
if !(profiles.nil? or profiles == [])
profiles.each do |s|
#block odd error where cache appends a :@new_record after the last result
next if !s.is_a?(Supplier) or s.address.nil? or s.address.country.nil?
...
The error, if I don't screen out the @new_record [this is not from cutting the line from the above code, but rather from another place I tried to use caching where a class-based test wasn't feasible]:
2013-08-28T20:50:00.446550+00:00 heroku[web.1]: State changed from starting to up
2013-08-28T20:50:06.774001+00:00 app[web.1]: Dalli/SASL authenticating as af5c2c
2013-08-28T20:50:06.777925+00:00 app[web.1]: Dalli/SASL: af5c2c
2013-08-28T20:50:06.807129+00:00 app[web.1]: Started GET "/suppliers" for 70.36.146.74 at 2013-08-28 20:50:06 +0000
2013-08-28T20:50:10.671553+00:00 app[web.1]:
2013-08-28T20:50:10.671553+00:00 app[web.1]: 37: <td>
2013-08-28T20:50:10.671553+00:00 app[web.1]: ActionView::Template::Error (undefined method `name' for :@new_record:Symbol):
2013-08-28T20:50:10.671553+00:00 app[web.1]: 39: <%= link_to s.name, supplier_profile_path(s.name_for_link) %>
2013-08-28T20:50:10.671553+00:00 app[web.1]: 40: <%= image_tag
application.rb's relevant bit:
module Partreach
class Application < Rails::Application
config.cache_store = :dalli_store
production.rb's relevant bit:
Partreach::Application.configure do
# Settings specified here will take precedence over those in config/application.rb
# Code is not reloaded between requests
config.cache_classes = true
# Full error reports are disabled and caching is turned on
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
Gemfile's relevant bit:
gem 'dalli', '2.6.4' #https://devcenter.heroku.com/articles/building-a-rails-3-application-with-memcache
gem 'memcachier', '0.0.2' #https://devcenter.heroku.com/articles/building-a-rails-3-application-with-memcache
I previously ran into the same thing. Its even listed on on the issues page for dalli -- but it's not limited to it.
You can find more info here: https://github.com/mperham/dalli/issues/250
And on the rails issues page too: https://github.com/rails/rails/issues/8020
And this workaround resolved it for me: https://github.com/rails/rails/issues/10322#issuecomment-16913855