You can clone with
HTTPS or Subversion.
I'm currently using rails 3.2.3 with friendly_id 4.0.7. In my configuration I can't cache a model when I enable friendly_id for it.
My model is like:
class ModelName < ActiveRecord::Base
friendly_id :name, :use => [:slugged]
Rails.cache.fetch('BRAND_ALL', :expires_in => 24.hours) do
whenever I try to access the all function I get the following error:
can't dump anonymous class #Class:0x00000004eb9278
activesupport (3.2.3) lib/active_support/cache.rb:561:in dump'
activesupport (3.2.3) lib/active_support/cache.rb:561:ininitialize'
activesupport (3.2.3) lib/active_support/cache.rb:363:in new'
activesupport (3.2.3) lib/active_support/cache.rb:363:inblock in write'
activesupport (3.2.3) lib/active_support/cache.rb:520:in instrument'
activesupport (3.2.3) lib/active_support/cache.rb:362:inwrite'
activesupport (3.2.3) lib/active_support/cache.rb:299:in fetch'
actionpack (3.2.3) lib/action_controller/metal/implicit_render.rb:4:insend_action'
activesupport (3.2.3) lib/active_support/cache.rb:561:in
activesupport (3.2.3) lib/active_support/cache.rb:363:in
activesupport (3.2.3) lib/active_support/cache.rb:362:in
actionpack (3.2.3) lib/action_controller/metal/implicit_render.rb:4:in
It seams to be a problem related to marshalling, have you ever encountered something similar?
Still present if you use Rails 3.2.6?
Can you please include the full stack trace? I can imagine a few places this might come from and possibly be fixed, and the full stack trace that includes lines from FriendlyId would be helpful.
Hi, solved was my fault (I was caching a scope result). It was quite strange that the error ws present only with friendly_id enabled
I have a similar issue.
I'm getting the error:
TypeError in Store::CartController#show
can't dump anonymous class #Class:0x007fb634cca9d8
I'm not using caching...but sessions.
I'm using sessions for a cart. Something like this:
@items = 
@items << product
product = Product.find(params[:id]) #this would be the slug
@cart = session[:cart] ||= Cart.new
Now in my view:
@cart.items.each do |item|
item.name #works fine
item.category.name #causes the error
Here's the link to the trace. If I comment out friendly id in the
Gemfile and remove the friendly_id references from my models, it works
** Strange bit: I'm using pry to debug. I can insert binding.pry
anywhere before the view reference to the association
(item.category.name) and have no problem accessing the objects and their
Thanks for the detailed info, @jess, that's super helpful. I'm on paternity leave right now and don't have much time to look at this for the next week or two, but if I get a chance to look I will. In the mean time I'll reopen the issue in case anyone else has a chance to work on it.
To that end, anybody looking to track this down might want to have a look here which I think is the likely source of the marshall error (also brought up in issue #306). I'm not sure if simply naming the class is sufficient to avoid the marshall error, but it may be worth looking into.
Hi @norman, congrats on the baby, your first?
I extracted out the code that was giving me problems into a really simple sample app. Sorry I don't know enough to help fix the issue, but maybe this will help narrow the focus.
Here's a screencast showing the issue: http://screencast.com/t/jckhaAfM5Y11
Here's the sample app: https://github.com/jess/test_friendly_id
There are 2 branches, master works, friendly_id branch breaks.
Hopefully I'm not making a dumb mistake somewhere, because it seems pretty basic setup??
Let me know if I can help more.
Good example application - thanks for including the screencast. It is indeed the fault of the code that @norman pointed out earlier and I'm currently looking to see if we can use something else.
Added tests to prove Marshal behaviour.
The relationship test fails when Marshaling.
I've added a test case to reproduce this issue which fails as expected and I'm out of time right now to continue looking. Hopefully this helps the next person (or future @parndt).
Name anonymous class to fix marshalling.
Just committed the fix for this and will push out a new version today. Thanks again @jess for the help!
Nice, good job! I tried to fix it, but didn't know how to name the class (I wasn't aware of const_set).
Funny, I ran into the same (or at least similar) issue with carrier wave (carrierwaveuploader/carrierwave#793). Any advice for those guys? I'd guess they're doing the same thing...creating an anonymous class for versions.