Sign in through GitHub

Please read for an updated status on RailsCasts:

Learn more or hide this

Brian Goff's Profile

GitHub User: cpuguy83

Comments by Brian Goff

Avatar

And it's good to do it that way, otherwise you start running into premature optimization.

Avatar

Still not getting around having to wrap your code into a cache block, but check out:
https://github.com/cpuguy83/pack_rat

It just lets you call:

ruby
def some_method
  cache do
    # stuff
  end
end
Avatar

cache_digests is for generating md5 digests of your fragments and inserting them into the cachekey for the object you are caching, this is for caching in the model itself.

Avatar

This episode makes me a little sad.
It's almost easier to setup Faye to handle this.

Avatar

No, the updated_at timestamp is coming from the object you've already pulled... specifically this is generated using the cache_key method on your object. Then it's generating an MD5 of your template to see if it's changed and adding that into the key being stored in memcache.

Avatar

I've messed with both.
It should be a fairly simple transition, assuming you aren't using things that have been deprecated in Rails 3 (which would be removed in Rails 4)... and of course assuming you are at least on Rails 3.1. The Asset Pipeline is a fairly large hurdle.

Avatar

You must 'CREATE EXTENSION hstore' first

Avatar

And what is wrong with that?

If the business logic is related to that model class and only that model class, then it should go there.

A fat model is not a bad model, so long as your model isn't fat because it's including functionality that belongs to another class.

Avatar

cache_digests and fragment caching is 1 piece of the puzzle.
Rendering out templates is actually pretty heavy on the server as well. Using this method will get you closer (performance-wise) to using a full client side JS solution, which takes all the fun out of using Rails.

If your controller actions are heavy then considering caching the underlying data as well.
In various places in my app I'm using:
1. Just fragment cachine
2. Fragment caching + action caching
3. Model caching + fragment caching

I'm not too fond of action caching, but it does speed things up tremendously if you can use it.

Avatar

This is specifically for fragment caching.
JSON would need to get cached by directly calling Rails.cache.fetch in your model or controller.

Avatar

But there are no hoops.
You install this gem and it does the work for you.

Avatar

You aren't caching the lists themselves, just the individual objects.
When you setup your associations you do the ":touch => true" option so the related object gets touched, thus automatically expiring the cache on it.

Avatar

Yep!

Even starting to wonder if N+1 issues can be mitigated with fragment caching instead of always having the server do the include at the action.

Avatar

Also, this is exactly why people use client-side frameworks like Backbone, Ember, Spine, etc.... instead of having the server spend the time rendering it, it just sends the json data to the client's browser where the framework figures out how to render it.

Avatar

Because when it comes time to push to production you would either have to update all your versions in each render call or manually clear your cache (something like Rails.cache.clear).
Using cache_digests you not only get auto-expiration of what should expire, but also get to keep all your other cached items as well.

It just makes deployment much simpler.

Avatar

Rendering the ERB can be fairly intensive and time consuming as well.
Using this method gets you down to the <100ms page load times.

Avatar

I would imagine Rails 4 handles it a lot better once it's released.
The great thing about this is you get the benefits of schemaless data with your schema'd data... and you get to keep using AR.

Avatar

Nice bit to know about calling "my" to get the original context.
I'd started creating variables before the where clause so I could call them, I think "my" is better.

Love Squeel. Love that I don't have to mess with ARel.