Giter Club home page Giter Club logo

interlock's Introduction

Interlock

A Rails plugin for maintainable and high-efficiency caching.

DEPRECATED

No replacement.

License

Copyright 2007, 2008 Cloudburst, LLC. Licensed under the AFL 3. See the included LICENSE file. Portions copyright 2006 Chris Wanstrath and used with permission.

The public certificate for the gem is here.

If you use this software, please make a donation, or recommend Evan at Working with Rails.

Requirements

Features

Interlock is an intelligent fragment cache for Rails.

It works by making your view fragments and associated controller blocks march along together. If a fragment is fresh, the controller behavior won’t run. This eliminates duplicate effort from your request cycle. Your controller blocks run so infrequently that you can use regular ActiveRecord finders and not worry about object caching at all.

Invalidations are automatically tracked based on the model lifecyle, and you can scope any block to an arbitrary level. Interlock also caches content_for calls, unlike regular Rails, and can optionally cache simple finders.

Interlock uses a tiered caching layer so that multiple lookups of a key only hit memcached once per request.

Installation

First, compile and install memcached itself. Get a memcached server running.

You also need either memcache-client or memcached:

sudo gem install memcache-client

Then, install the plugin:

script/plugin install git://github.com/fauna/interlock.git

Lastly, configure your Rails app for memcached by creating a config/memcached.yml file. The format is compatible with Cache_fu:

defaults:
  namespace: myapp
  sessions: false
  client: memcache-client
development:
  servers:
    - 127.0.0.1:11211 # Default host and port
production:
  servers:
    - 10.12.128.1:11211
    - 10.12.128.2:11211

Now you’re ready to go.

Note that if you have the memcached client, you can use client: memcached for better performance.

Usage

Interlock provides two similar caching methods: behavior_cache for controllers and view_cache for views. They both accept an optional list or hash of model dependencies, and an optional :tag keypair. view_cache also accepts a :ttl keypair.

The simplest usage doesn’t require any parameters. In the controller:

class ItemsController < ActionController::Base

  def slow_action
    behavior_cache do
      @items = Item.find(:all, :conditions => "be slow")
    end
  end

end

Now, in the view, wrap the largest section of ERB you can find that uses data from @items in a view_cache block. No other part of the view can refer to @items, because @items won’t get set unless the cache is stale.

<% @title = "My Sweet Items" %>

<% view_cache do %>
  <% @items.each do |item| %>
    <h1><%= item.name %></h1>
  <% end %>
<% end %>

You have to do them both.

This automatically registers a caching dependency on Item for slow_action. The controller block won’t run if the slow_action view fragment is fresh, and the view fragment will only get invalidated when an Item is changed.

You can use multiple instance variables in one block, of course. Just make sure the behavior_cache provides whatever the view_cache uses.

See ActionController::Base and ActionView::Helpers::CacheHelper for more details.

Caching finders

Interlock 1.3 adds the ability to cache simple finder lookups. Add this line in config/memcached.yml:

with_finders: true

Now, whenever you call find, find_by_id, or find_all_by_id with a single id or an array of ids, the cache will be used. The cache key for each record invalidates when the record is saved or destroyed. Memcached’s multiget mode is used for maximum performance.

If you pass any parameters other than ids, or use dynamic finders, the cache will not be used. This means that :include works as expected and does not require complicated invalidation.

See Interlock::Finders for more.

Notes

You will not see any actual cache reuse in development mode unless you set config.action_controller.perform_caching = true in config/environments/development.rb.

If you have custom render calls in the controller, they must be outside the behavior_cache blocks. No exceptions. For example:

def profile
  behavior_cache do
    @items = Item.find(:all, :conditions => "be slow")
  end
  render :action => 'home'
end

You can write custom invalidation rules if you really want to, but try hard to avoid it; it has a significant cost in long-term maintainability.

Also, Interlock obeys the ENV['RAILS_ASSET_ID'] setting, so if you need to blanket-invalidate all your caches, just change RAILS_ASSET_ID (for example, you could have it increment on every deploy).

Further resources

Reporting problems

The support forum is here.

Patches and contributions are very welcome. Please note that contributors are required to assign copyright for their additions to Cloudburst, LLC.

interlock's People

Contributors

brett avatar chrisnolan avatar crowbot avatar evan avatar hrefhref avatar sudothinker avatar sujal avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

interlock's Issues

TypeError (can't modify frozen hash):

How does one disable the caching of a model? It seems that it's trying to cache the models when the Interlock plugin:

TypeError (can't modify frozen hash):
authlogic (2.1.3) lib/authlogic/session/magic_columns.rb:86:in set_last_request_at' authlogic (2.1.3) lib/authlogic/session/callbacks.rb:72:inafter_persisting'
authlogic (2.1.3) lib/authlogic/session/persistence.rb:59:in persisting?' authlogic (2.1.3) lib/authlogic/session/persistence.rb:39:infind'
vendor/extensions/sd_main/app/controllers/spree/base_controller.rb:182:in current_user_session' vendor/spree/vendor/extensions/api/api_extension.rb:58:incurrent_user'
vendor/extensions/sd_main/app/controllers/spree/base_controller.rb:140:in set_abingo_identity' vendor/gems/hoptoad_notifier-2.3.7/lib/hoptoad_notifier/rack.rb:27:incall'
/Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/httpserver.rb:104:in service' /Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/httpserver.rb:65:inrun'
/Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:173:in start_thread' /Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:162:instart'
/Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:162:in start_thread' /Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:95:instart'
/Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:92:in each' /Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:92:instart'
/Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:23:in start' /Users/ctaylor/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/webrick/server.rb:82:instart'

Rails 2.3.5 Combatibility?

Hi Evan

Was just using interlock on a Rails 2.3.5 and found issues like :ttl vs :expire for caches_action (we patched the action_controller to use :ttl ... but also noted that caches_action does not respect the :layout => false.

So my guess is that this plugin would need changes to work with 2.3.5 ?

One of our devs wants to still use it you see.

Cheers
Shane

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.