Ruby on Rails Caching Tutorial - 2 - Ruby on Rails Caching Tutorial

When your Ruby On Rails Website gets famous you're going to wish you implemented proper caching. Are you worried? Maybe just a little?

This tutorial is going to show everything you need to know to use Caching in your Rails applications, so when you get digg'd or slashdot'd you won't be left begging your hosting provider for more bandwidth.

Since there are so many different types of caching, I'm going to split this up into several blog entries. Each one will build on the previous, talking about more complex types of caching and how to implement them. We'll even discuss some advanced caching plugins people have written for customized caching.

Today we're going to dive into the FASTEST rails caching mechanism, page caching!

So you want to add rapid full-text searching to your Rails app, and either you haven't had much luck getting full text working with Mysql, or you want to start working with something a little more customizable (and very fast). This tutorial will let you know exactly how to do it.

Update: This article is now about reinventing the wheel and showing you how easy it is to use the ruby language to accomplish your tasks. As robert pointed out in the comments, rails comes with the reverse merge method which you could call instead.

In this article, I'm going to show you how to have the params keep their state on your page in a very easy, concise manner. In most Rails pages you're only going to be changing the params for one object, possibly two. Conventionally, it's done like this:

<%= link_to 'Previous page', { :page => @post_pages.current.previous } %>

But that becomes a problem if you want to have anything other than the page variable in your query string. A solution to that:

<%= link_to 'Previous page', { :page => @post_pages.current.previous }.merge(params.reject{|k,v| k=="page"}) %>

Not so bad if you only have a couple of links. But I'm lazy and strive for minimalist code. Try throwing something like this in your application_helper

1
2
3

def params_merge(opts={})
  opts.merge(params.reject{|k,v| opts.keys.include?(k)})
end

And you can now do this:

<%= link_to 'Previous page', params_merge(:page => @post_pages.current.previous) %>

You might be working with a RESTful application, in which case you may have some routes that are defined like this:

1
2
3
4
5
6

map.with_options :controller => 'surf_reports', :action => 'worldwide' do |worldwide|
  worldwide.global_news     '/news',     :category => 'news'
  worldwide.global_events   '/events',   :category => 'events'  
  worldwide.global_latest   '/latest',   :category => 'latest'
  worldwide.global_location '/location', :category => 'location'
end

Now you know your route for global_news_path already has a category set. Let's say you want to link to that with seven other params. You can't just do global_news_path(params) because you might be in /events at the time, which already has the category set. Just like above, you could do something like this:

<%= link_to "News", global_news_path(params.reject{|k,v| k=="category"}) %>

But this quickly becomes tedious. Try this in your application_helper:

1
2
3

def params_without(name)
  params.reject{|k,v| k==name}
end

And now you can do an easy link_to:

<%= link_to "News", global_news_path(params_without :category) %>

Now you have some view code that's concise and pretty.

Update!
Duncan Beevers posted the following in the comments if you want something to work on all of your hashes. Thanks, Duncan!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Hash

  # lets through the keys in the argument
  # >> {:one => 1, :two => 2, :three => 3}.pass(:one)
  # => {:one=>1}
  def pass(*keys)
    tmp = self.clone
    tmp.delete_if {|k,v| ! keys.include?(k) }
    tmp
  end

  # blocks the keys in the arguments
  # >> {:one => 1, :two => 2, :three => 3}.block(:one)
  # => {:two=>2, :three=>3}
  def block(*keys)
    tmp = self.clone
    tmp.delete_if {|k,v| keys.include?(k) }
    tmp
  end

end

Hello, and welcome to Rails Envy. This is a blog written by Gregg Pollack and Jason Seifer about web development, dealing with clients, programming, javascript, ruby, and (here's the surprising one) Ruby on Rails. And maybe some other things that fall in line with those subjects. And possibly pie.

Who We Are

Gregg Pollack has been developing web applications for 8 years now and has been working full time with Ruby on Rails for 2 1/2 years. Gregg started the Orlando Ruby Users Group and is currently the CTO of Patched Software. Gregg is also a recovering Java programmer. You can help Gregg stay on the bus by coding in Ruby too.

Jason Seifer graduated from the University of Central Florida with a degree in Psychology and is a senior programmer at Patched Software. He never had any formal training other than a few odd programming classes in college but always had a passion for programming and things seemed so much more fun after finding Ruby.

What this blog is for.

We work with Ruby and Rails full time. When you do something full time, you tend to pick up little tricks along the way. You constantly overcome hurdles that make you a better programmer and problem solver. We decided it's time to share some of these gems in the hopes that it can help other people learn and understand. Also, we love Ruby and Rails, so that helps too. We hope you enjoy this blog and look forward to your comments.