Hello, was trying to see if I could use this lib in an older app I maintain. But in testing it I'm always getting the same key generated for a given class/method/arg. For example I have a really simple AR class to test with
class Zipcode < ActiveRecord::Base
And in an initializer i'm setting the store to be the default Rails store
MethodCacheable.config do |config|
config.store = Rails.cache
This is what I'm seeing in a console session and looking at the key generated for different args
Loading production environment (Rails 3.0.12)
1.8.7 :001 > Zipcode.new.cache.test_key(0)
1.8.7 :002 > Zipcode.new.cache.test_key(1)
1.8.7 :003 > Zipcode.new.cache.test_key(2)
Am I doing something silly wrong in using this? Any insight appreciated, thanks!
With method_cacheable you don't need to use define_keys unless you need to over-write a key. That may be the issue.
You can get the key from the cache directly if you need, it may help with debugging:
cache = Zipcode.find(263619).cache # => #<MethodCacheable::MethodCache ... >
cache.method = "foo"
cache.key # => "zipcode:foo:263619"
Is the Zipcode saving to the database? What version of Method Cacheable and what version of Keytar are you using, you can check the Gemfile.lock.
Ok, thanks for the tip on removing define_keys. And, no I'm not currently trying to save a zipcode to the db. Was just trying to store some arbitrary (long) method calls in the cache while checking out the gem. But the values were always the same.
The gem versions I'm using are
Testing your way, I still see this with different args
cache = Zipcode.new.cache # => #<MethodCacheable::MethodCache
cache.method = 'test'
cache.args = 1
cache.key # => "zipcodes:test"
cache.args = 2
cache.key # => "zipcodes:test"
So this happens to be within a RefineryCMS app, I'm starting to believe maybe there's something in Refinery that is mucking with the key generation. I'll keep digging and let you know if I figure it out.
Since the ZipCode does not have a valid id because it is not yet saved, it doesn't know what to do.
1.9.3dev :017 > User.last.cache.key("foo", 1)
User Load (0.8ms) SELECT "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT 1
1.9.3dev :018 > User.new.cache.key("foo", 1)
Also cache.args is expected to be an array. The solution is to use create instead of new
So you can't cache class methods? Is that intended?
It works just fine on class methods:
1.9.3dev :006 > User.cache.key("foo", 1)
1.9.3dev :007 > User.cache.key("foo", 2)
Well, the key generation seems ok, it's something else, at least for me. Do you not see this behavior with this simple Class example in a Rails app. I also removed the ActiveRecord inheritance to simplify things.
1.8.7-p370 :001 > SomeClass.cache.key('test', 0)
1.8.7-p370 :002 > SomeClass.cache.key('test', 1)
1.8.7-p370 :007 > SomeClass.test(0)
1.8.7-p370 :008 > SomeClass.test(1)
1.8.7-p370 :005 > SomeClass.cache.test(0)
1.8.7-p370 :006 > SomeClass.cache.test(1)
Perhaps I'm not seeing some obvious problem. Hopefully I'm not being too annoying ;-) I appreciate the replies.
it's a bug, i figured it out, working on a fix now...thanks for your patience
close #3 properly use args if tmp_args not passed
Pushed a fix in version 0.1.0 of the gem, let me know if you have more problems. Sorry about that.