Is a find_by_sql query cached with memcached and cached_model
(dev.robotcoop.com)? Looks like the answer is no. Is
there a reason for this? I have a lot of very complicated querys with a
lot of unions, subquerys and joins that would greatly benefit from the
cache.
Going through the code I can see that the find_by_sql method is changed
in cached_model.rb, but it does not call Cache.get or cache_store. Why?
I am tempted to add it…
On Jan 30, 2006, at 11:19 AM, Simon S. wrote:
Is a find_by_sql query cached with memcached and cached_model
(dev.robotcoop.com)? Looks like the answer is no. Is
there a reason for this? I have a lot of very complicated querys
with a
lot of unions, subquerys and joins that would greatly benefit from the
cache.
Then cache them by hand.
Going through the code I can see that the find_by_sql method is
changed
in cached_model.rb, but it does not call Cache.get or cache_store.
Why?
I believe in Rails 1.0 associations don’t go through
ActiveRecord::Base::find but instead go straight to
ActiveRecord::Base::find_by_sql. This was not true in earlier
versions of Rails.
The overridden method merely causes the lookup to run through
CachedModel::find when an association is being looked up so the cache
will be hit.
I am tempted to add it…
You’ll likely run into hard-to-debug behavior if you do that for all
queries. The real problem is the invalidation strategy. There is no
easy way to determine the dependencies between the component records
of the query and the query result itself. Without knowing the
dependencies you don’t know which record updates will cause the
complex query to become invalid. This could have grave consequences
for your application.
I recommend you use memcache at a higher level (in your models) for
complex queries. This way you can define an acceptable level of
staleness or an invalidation strategy that won’t lead you to great pain.
–
Eric H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant