I am page caching a list of products - products.json in the public directory under the rails root.
I don't add or delete this data through a controller action. This data is loaded into the database
through a data migration script. In the development environment I delete this file from the public
directory and restart the mongrel server but it is still pulling up the cached data. Not sure from where. How do I expire this cache data.
thanks much,
ash
Have you tried?
rake cache:clear
You have to figure out where the data is being cached. Are you sure that, after you delete the cached version from /public, the data you see on the website is in fact getting pulled from the cache? Because if the base data have not changed, then of course it will recache it the moment is it re-requested (that's how page caching works, if the cache isn't present it regenerates it).
Also, note that there are different data stores available for caching: disk, memory, and more complex solutions (like Memcached). If you see differences between development and production, it could be that you are caching in different places in different environments.
If you want something that will really trash cached files on disk, you may want to try http://github.com/factore/cache_trasher
Related
I have created rails application and I have used fragment caching concept. Where is cached data getting stored and how can I access those data? How do I know whether caching is working or not?
Take a look into fragment caching docs for references (you are particularly interested in ActionController::Caching::Fragments).
You may want to check
ActiveSupport::Cache.expand_cache_key(key, namespace)
to check specific key for whether it is being cached.
To check the cache storage you can check the
config.action_controller.page_cache_directory
P.S. It's high time to upgrade your Rails version ;)
Eventually I got the solution.
Cached data will stored based on cache_store used in environment configuration.
Ex)
Some available cache_stores are memory_store, file_store,.. etc
I have configured file_store in development environment then the data will be stored in rails_root/tmp/cache directory
I have a rails application.
I am using membase/memcache to cache DB objects and HTML partials.
I cache db objects with the create operation and of course find operations etc...
now, when I do User.find(1).
this is cached as an object in memcache.
I have a pretty good strategy with caching these along side with the HTML content.
now, when I deploy, one of the thing my Capistrano script is doing is to clear the cache (because of the html partials that change) but there's really no reason to invalidate the cache of the db objects.
How can I only delete part of my cache?
Can this be done?
my cache keys look like this
DB: user_find_by_id_10000
HTML: user_profile_home_1000
Would appreciate you help
Thanks.
It might also be a good idea to user separate buckets for your DB cache and your HTML cache...then you can use the 'flush_all' command to clear out a whole bucket without affecting the other one.
Also, looking forward to Couchbase Server 2.0 which will be in a developer preview at the end of this week, you'll be able to create indexes and views to return just the data that you're looking for, you can then feed that through a little process to delete all the items that match a certain criteria.
Perry Krug
Solutions Architect, Couchbase Inc.
It's fairly simple to delete a cached item based on its key:
Rails.cache.delete('user_profile_home_1000')
In the code above I'm assuming you've set Rails' cache to use Memcached.
I'm wondering if there's a way to store CSS asset paths, like background images, in the database so that they're customizable without accessing or rewriting the code. I've looked at some template engines, like liquid, but think they're a overkill for what I want to do. I only want a tiny bit of customization in my views between various deployments of the same app codebase, not anything for various users.
I've not looked much at Rails 3.1, but from what I understand the CSS assets are compiled and aren't static any longer, so -- does that mean I can write something like that into my CSS in rails 3.1 that pulls from the database? I usually deploy to Heroku and aren't sure if they're supporting 3.1 yet.
Anyone have any better strategies or ideas?
Storing binary files like images in the database can quickly become cumbersome. There was a time when we were storing user uploads like PDF's and such in the DB but it became unmanageable. We quickly moved it all over to S3 and made Paperclip store and retrieve the files there (encrypting the files before saving them to S3, and sending them over SSL since the files were potentially sensitive) and it made things much saner.
I'd say best bet for you is to use S3. Since
On heroku you have a limited
database size (depending on your
plan) and could quickly run out if
you're storing binaries there.
You can't dynamically save new files
to the filesystem on heroku, and
S3 is cheap as hell (and free for
most casual use) to store and
retrieve files.
EDIT based on your comment:
Ok I mis-understood the question. Either store the image path in the database or have the image stored with such a path & naming convention that the code itself can figure out where to get the image (which is what paperclip does). Both ways are acceptable. NOTE that SASS is not truly dynamic, you can't pull paths from the database and make the sass change on-the-fly. I've run into a similar situation and the solution was to make the CSS point to a background-image that was in fact a route in the application. In our instance we were able to change the image displayed based on the subdomain or domain of the incoming user, but you could just as easily display that image based on a session cookie that gets set before the views are rendered.
While SASS is compiled, after it's been generated it is static. The syntax, and 'dynamic' nature of it are just to make writing CSS easier.
What about using something like S3(Paperclip) + a "css assets" table/model?
That way in an "admin" page you can pull all of the possible CSS assets, allow someone to select a new one or even upload a new image to s3. This means you wouldn't have to actually rewrite any code just have an admin portal where they can select possible images.
I'm trying to optimize my application and load certain things into the Rails cache (eventually memcached) at application start. Essentially I have a few tables in my database that only exist for normalization purposes and RARELY change. When they change, I can handle the logic to update the cache.
Where should I write the 'initializer' to read these various models and load them into the cache? I tried writing a traditional initializer, but it gets run BEFORE my models actually exist... I essentially need to load all my models and stuff, then create the cache, then run the application. How can I enter that middle state?
I would either put this code in a file in your lib directory and require the model files first, or directly into your model files so that the initialization runs after your model is defined:
class NormalizedTable
...
end
CacheInitializer.fill_cache_with :normalized_table
Where CacheInitializer#fill_cache_with is defined in your initializers or lib directory. I would also recommend that you run these functions in the background, for example in a delayed job. If you are running this code every time you load up your Rails app it will slow your boot process down and it's probably not necessary that the data is in your cache at all times - i.e you app can use the database while the cache is being populated.
As a developer new to Rails, I'd like to know what checklists seasoned Rails developers might have of things to check before putting a Ruby on Rails web site live. I am thinking that you should probably remove generated views that you aren't using, remove controller actions you don't need, remove default routes and so forth.
I'm thinking there could be a list for performance and another for security..?
Security
Disable Apache script processing for the public directory.
filter_parameter_logging :password in application_controller.rb (and password_confirmation, credit card numbers etc.)
Make sure you require SSL for login, credit card processing
Performance
Cache everything you can, especially the front page
Look at this question: what-should-a-developer-know-before-building-a-public-web-site
Make sure you have a cron job backing up your database (and user's uploaded files!).
Replication is not backup.
RAID is not backup.
Databases can get corrupted. (Including by your own buggy code.)
Data can be hacked.
When that happens, you need a backup.
Not just a single copy: keep checkpoints in case your db gets corrupted and you don't notice before the backup runs.
Not just on the same server/drive as the database itself on case the drive is unrecoverably hosed.
Remember what happened to ma.gnolia.com
Don't let it happen to you.