Great one, thank you!
Monday started as always with Ryan
s screencast - it mean it will be great week as always! ;)
Cheers
In this use case, you can probably just use a counter cache on belongs_to association, as it will store comments_count information in Article table, so it will be updated each time a comment is inserted.
But anyway, good screencast showing this cool new feature although I don't see any other use case that caching for that one.
(Audio problems was not a big deal for me, it's understandable)
Cheers
Nice screencast but is there any built in way to recover space from previously expired caches or would this have to be set up as some sort of a cron job to go through and delete the old ones?
@EppO you wouldn't want to do that in case you wanted to add the ability to update a comment, the count wouldn't change.
I suppose in the limited functionality the blog Ryan uses that would work fine, but in the spirit of scaling using the cache_key will always work!
@Chris, it depends what cache store you are using. It defaults to file based store which you will need to set up some kind of cron task to remove old caches.
If you set it up to use a memcache store it will roll off the old caches automatically when it reaches the set memory limit.
@Ryan: Nice video.
@all: I am rails evangelist and currently using it to make my personal web blog. I want to print friends blogging activity on user home page. Is there any recommended tutorial or pointers to accomplish that. I thought of using cache but thinking there could be a better way.
While this seems neat, is there really a big benefit to it? You will be hitting the article table everytime to get the cache key, right?
So you're still hitting the database a lot; You do avoid the comment queries, but it seems silly to be fetching the entire article model just to get the caching key. Seems a rather naive way of trying to scale up, particularly considering article is the one thing that is likely NOT to change, making it the perfect thing to cache in the first place.
Maybe you could provide some insights as to why you would use this, as it seems to be a pretty short-sighted way of making the page scale; why not just add the caching key expiration in the first place, it's not as though it's hard or messy?
@Thomas, as mentioned near the beginning of this episode, there are other caching solutions which may work better in this scenario. This is more about showing off another technique for your caching repertoire.
The most optimized approach here is page caching. However, that requires you set up a sweeper on both article and comment and is a bit more complex.
The solution shown here works best when you have a heavy page where you are fetching a lot of related data that relies all on a single model. It might be a user profile page for example.
About a year ago I wrote a plugin to provide touch functionality to models. I've been using it to fuel another plugin of mine I call conflict warnings(http://github.com/EmFi/conflict_warnings). To deal with the the race condition that arises when two users modify the same resource asynchronously.
It relies heavily on touch because the pages I have a user acting on, are usually a collection of child records. Caching is a big help in this respect.
I Really like your stuff, your a source of inspiration when it comes to discipline!
Thanks for all your hours of effort and work you've put out there for us!
Seriously, if you guys add caching, you would dominate the world. Thanks for the nice blog!
Adidas Shoes Online Shop-Hot Selling Adidas Shoes & Cheap Adidas Shoes.
my
I Really like your stuff, your a source of inspiration when it comes to discipline!
I have a user acting on, are usually a collection of child records.
Thanks for all your hours of effort and work you've put out there for us!
on iTunes
