Cache
Avo uses the application's cache system to enhance performance. The cache system is especially beneficial when dealing with resource index tables and license requests.
Cache store selection
The cache system dynamically selects the appropriate cache store based on the application's environment:
Production
In production, if the existing cache store is one of the following: ActiveSupport::Cache::MemoryStore
or ActiveSupport::Cache::NullStore
it will use the default :file_store
with a cache path of tmp/cache
. Otherwise, the existing cache store Rails.cache
will be used.
Test
In testing, it directly uses the Rails.cache
store.
Development and other environments
In all other environments the :memory_store
is used.
Custom selection
You can force Avo to use a particular store.
# config/initializers/avo.rb
config.cache_store = -> {
ActiveSupport::Cache.lookup_store(:solid_cache_store)
}
# or
config.cache_store = ActiveSupport::Cache.lookup_store(:solid_cache_store)
cache_store
configuration option is expecting a cache store object, the lambda syntax can be useful if different stores are desired on different environments.
MemoryStore
in production
Our recomendation is to not use MemoryStore in production because it will not be shared between multiple processes (when using Puma).
-> cache_hash
The cache_hash
method is used to compute the cache key for each row.
More about this on the resource options page.
Caching caveats
Avo caches each record on the Index
view for improved performance. However side-effects may occur from this strategy. We'll try to outline some of them below and keep this page up to date as we find them or as they get reported to us.
These are things that may happen to regular Rails apps, not just in the Avo context.
Rows may not be automatically updated when certain associations change
There are two things you could do to prevent this:
Option 1: Use touch: true
on association
Example with Parent Model and Association
class Post < ApplicationRecord
has_many :comments, dependent: :destroy
end
Example with Child Model and Association with touch: true
class Comment < ApplicationRecord
belongs_to :post, touch: true
end
Option 2: override cache_hash
method on resource to take associations in consideration
Avo, internally, uses the cache_hash
method to compute the hash that will be remembered by the caching driver when displaying the rows.
You can take control and override it on that particular resource to take the association into account.
class Avo::Resources::User < Avo::BaseResource
def fields
# your fields
end
def cache_hash(parent_record)
# record.post will now be taken under consideration
result = [record, file_hash, record.post]
if parent_record.present?
result << parent_record
end
result
end
end
root_path
change won't break the cache keys
When the rows are cached, the links from the controls, belongs_to
and record_link
fields, and maybe others will be cached along.
The best solution here is to clear the cache with this ruby command Rails.cache.clear
. If that's not an option then you can try to add the root_path
to the cache_hash
method in your particular resource.
Solid Cache
Avo seamlessly integrates with Solid Cache. To setup Solid Cache follow these essential steps
Add this line to your application's Gemfile:
gem "solid_cache"
And then execute:
$ bundle
Or install it yourself as:
$ gem install solid_cache
Add the migration to your app:
$ bin/rails solid_cache:install:migrations
Then run it:
$ bin/rails db:migrate
To set Solid Cache as your Rails cache, you should add this to your environment config:
config.cache_store = :solid_cache_store
Check Solid Cache repository for additional valuable information.