djmaze-arid_cache 1.1.0

data/.gitignore

@@ -0,0 +1,26 @@
+## MAC OS
+.DS_Store
+
+## TEXTMATE
+*.tmproj
+tmtags
+
+## EMACS
+*~
+\#*
+.\#*
+
+## VIM
+*.swp
+
+## PROJECT::GENERAL
+coverage
+rdoc
+pkg
+Gemfile.lock
+.bundle/*
+
+## PROJECT::SPECIFIC
+test/**/*.log
+test/tmp/*
+tmp

data/Gemfile

@@ -0,0 +1,18 @@
+# A sample Gemfile
+source "http://rubygems.org"
+
+gem 'activerecord', '=2.3.8'
+gem 'activesupport', '=2.3.8'
+gem 'sqlite3-ruby', '=1.3.1'
+
+gem 'will_paginate', '=2.3.15'
+gem 'jeweler', '=1.4.0'
+
+gem 'ruby-debug', '=0.10.3'
+gem 'ruby-debug-base', '=0.10.3'
+gem 'machinist', '=1.0.6'
+gem 'faker', '=0.3.1'
+gem 'rspec', '=1.3.0', :require => 'spec'
+gem 'test-unit', '=1.2.3'
+gem 'mocha', '=0.9.8'
+gem 'arid_cache', :path => "./"

data/LICENSE

@@ -0,0 +1,20 @@
+Copyright (c) 2009 Karl Varga <kjvarga@gmail.com>
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.rdoc

@@ -0,0 +1,394 @@
+= AridCache
+
+AridCache makes caching easy and effective.  AridCache supports caching on all of your ActiveRecord model named scopes, class and instance methods right out of the box.  AridCache keeps caching logic out of your model methods and clarifies your view code by making calls to cached result sets explicit.
+
+AridCache supports caching large, expensive ActiveRecord collections by caching only the model IDs, provides efficient in-memory pagination of your cached collections, and gives you collection counts for free.  Non-ActiveRecord collection data is cached unchanged allowing you to cache the results of any expensive operation simply by prepending your method call with <tt>cached_</tt>.
+
+AridCache simplifies caching by supporting auto-expiring cache keys - as well as common options like <tt>:expires_in</tt> - and provides methods to help you manage your caches at the global, model class, model instance and per-cache level.
+
+== Changes
+
+v1.0.5: Support <tt>:raw</tt> and <tt>:clear</tt> options.
+
+== Install
+
+<b>Rails 3:</b>
+
+Add the gem to your `Gemfile`
+
+  gem 'arid_cache'
+
+Then
+
+  bundle install
+
+For some reason AridCache is not being included into ActiveRecord, so add the following to an initializer to get around that until I fix it:
+
+  AridCache.init_rails
+
+<b>Rails 2:</b>
+
+Add the gem to your <tt>config/environment.rb</tt> file:
+
+  config.gem 'arid_cache'
+
+Then
+
+  rake gems:install
+
+== Introduction
+
+The name AridCache comes from <b>A</b>ctive<b>R</b>ecord *ID* Cache.  It's also very DRY...get it? :)
+
+Out of the box AridCache supports caching on all your ActiveRecord class and instance methods and named scopes...basically if a class or class instance <tt>respond_to?</tt> something, you can cache it.
+
+The way you interact with the cache via your model methods is to prepend the method call with <tt>cached_</tt>.  The part of the method call after <tt>cached_</tt> serves as the basis for the cache key.  For example,
+
+  User.cached_count            # cache key is arid-cache-user-count
+  genre.cached_top_ten_tracks  # cache key is arid-cache-genres/<id>-top_ten_tracks
+
+You can also define caches that use compositions of methods or named scopes, or other complex queries, without having to add a new method to your class.  This way you can also create different caches that all use the same method.  For example,
+
+  # cache key is arid-cache-user-most_active_users
+  User.cached_most_active_users do
+    active.find(:order => 'activity DESC', :limit => 5)
+  end
+
+=== ActiveRecord Collections
+
+If the result of your <tt>cached_</tt> call is an array of ActiveRecords, AridCache only stores the IDs in the cache (because it's a bad idea to store records in the cache).
+
+On subsequent calls we call <tt>find_all_by_id</tt> on the target class passing in the ActiveRecord IDs that were stored in the cache.  AridCache will preserve the original ordering of your collection (you can change this using the <tt>:order</tt>).
+
+The idea here is to cache collections that are expensive to query.  Once the cache is loaded, retrieving the cached records from the database simply involves a <tt>SELECT * FROM table WHERE id IN (ids, ...)</tt>.
+
+Consider how long it would take to get the top 10 favorited tracks of all time from a database with a million tracks and 100,000 users.  Now compare that to selecting 10 tracks by ID from the track table.  The performance gain is huge.
+
+=== Base Types and Other Collections
+
+Arrays of non-ActiveRecords are stored as-is so you can cache arrays of strings and other types without problems.
+
+Any other objects (including single ActiveRecord objects) are cached and returned as-is.
+
+=== Example
+
+An example of caching using existing methods on your class:
+
+  class User < ActiveRecord::Base
+    has_many    :pets
+    has_one     :preferences
+    named_scope :active, :conditions => [ 'updated_at <= ', 5.minutes.ago ]
+  end
+
+  User.cached_count          # uses the built-in count method
+  User.cached_active         # only stores the IDs of the active users in the cache
+  User.cached_active_count   # returns the count of active users directly from the cache
+
+  user.cached_pets_count     # only selects the count until the collection is requested
+  user.cached_pets           # loads the collection and stores the pets IDs in the cache
+
+== Defining Your Caches
+
+=== Dynamically
+
+To dynamically define caches just pass a block to your <tt>cached_</tt> calls.  Caches can be defined on your classes or class instances.  For example,
+
+  User.cached_most_active_users do
+    active.find(:order => 'activity DESC', :limit => 5)
+  end
+
+  => [#<User id: 23>, #<User id: 30>, #<User id: 5>, #<User id: 2>, #<User id: 101>]
+
+  user.cached_favorite_pets do
+    pets.find(:all, :conditions => { 'favorite' => true })
+  end
+
+  => [#<Pet id: 11>, #<Pet id: 21>, #<Pet id: 3>]
+
+=== Configuring Caches on your Models
+
+We can clean up our views significantly by configuring caches on our model rather than defining them dynamically and passing options in each time.  You configure caches by calling <tt>instance_caches(options={})</tt> or <tt>class_caches(options={})</tt> with a block and defining your caches inside the block (you don't need to prepend <tt>cached_</tt> when defining these caches because we are not returning results, just storing options).
+
+You can pass a hash of options to <tt>instance_caches</tt> and <tt>class_caches</tt> to have those options applied to all caches in the block.  The following is a more complex example that also demonstrates nested cached calls.
+
+  # app/models/genre.rb
+  class Genre
+    class_caches do
+      most_popular do
+        popular(:limit => 10, :order => 'popularity DESC')
+      end
+    end
+
+    instance_caches(:order => 'release_date DESC') do
+      highlight_tracks(:include => [:album, :artist]) do
+        cached_tracks(:limit => 10, :include => [:album, :artist])
+      end
+      highlight_artists(:order => nil) do   # override the global :order option
+        cached_artists(:limit => 10)
+      end
+      highlight_albums(:include => :artist) do
+        cached_albums(:limit => 3, :include => :artist)
+      end
+    end
+  end
+
+  # app/controllers/genre_controller.rb
+  @most_popular = Genre.cached_most_popular
+  @tracks  = @genre.cached_highlight_tracks
+  @artists = @genre.cached_highlight_artists
+  @albums  = @genre.cached_highlight_albums
+
+You can configure your caches in this manner wherever you want, but I think the model is a good place.  If you wanted to move all your cache configurations to a file in <tt>lib</tt> or elsewhere, your calls would look like,
+
+  Genre.class_caches do
+    ...
+  end
+  Genre.instance_caches do
+    ...
+  end
+
+== Cache Keys
+
+AridCache cache keys are defined based on the methods you call to interact with the cache.  For example:
+
+  Album.cached_featured_albums  => cache key is arid-cache-album-featured_albums
+  album.cached_top_tracks       => cache key is arid-cache-albums/<id>-top_tracks
+
+Caches on model instances can be set to automatically incorporate the ActiveRecord <tt>cache_key</tt> which includes the <tt>updated_at</tt> timestamp of that instance, making them auto-expire when the instance is updated.
+
+To incorporate the the <tt>cache_key</tt> pass <b><tt>:auto_expire => true</tt></b> to your cache method:
+
+  album.cached_top_tracks(:auto_expire => true) => cache key like arid-cache-albums/2-20091211120100-top_tracks
+
+Or via the cache configuration:
+
+  Album.instance_caches do
+    top_tracks(:auto_expire => true)
+  end
+
+If you need to examine values in the cache yourself you can build the AridCache key by calling <tt>arid_cache_key('method')</tt> on your object, whether it is a class or instance.  Using the examples above we would call,
+
+  Album.arid_cache_key('featured_albums') => arid-cache-album-featured_albums
+  album.arid_cache_key('top_tracks')      => arid-cache-albums/2-top_tracks
+  album.arid_cache_key('top_tracks', :auto_expire => true) => arid-cache-albums/2-20091211120100-top_tracks
+
+== Managing your Caches
+
+=== Deleting & Expiring Caches
+
+AridCache provides methods to help you clear your caches:
+
+  AridCache.clear_caches      => expires all AridCache caches
+  Model.clear_caches          => expires class and instance-level caches for this model
+  Model.clear_instance_caches => expires instance-level caches for this model
+  Model.clear_class_caches    => expires class-level caches for this model
+
+The <tt>Model.clear_caches</tt> methods are also available on all model instances.
+
+<B>Your cache store needs to support the <tt>delete_matched</tt> method for the above to work. Currently MemCacheStore and MemoryStore do not.</b>
+
+Alternatively you can pass a <b><tt>:force => true</tt></b> option in your <tt>cached_</tt> calls to force a refresh of a particular cache, while still returning the refreshed results.  For example:
+
+  Album.cached_featured_albums(:force => true)  => returns featured albums
+  album.cached_top_tracks(:force => true)       => returns top tracks
+
+If you just want to clear a cache without forcing a refresh pass <b><tt>:clear => true</tt></b>.  The cached value will be deleted with no unnecessary queries or cache reads being performed.  It is safe to pass this option even if there is nothing in the cache yet.  The method returns the result of calling <tt>delete</tt> on your cache object.  For example:
+
+    Album.cached_featured_albums(:clear => true)  => returns false
+    Rails.cache.read(Album.arid_cache_key(:featured_albums)) => returns nil
+
+You can pass an <b><tt>:expires_in</tt></b> option to your caches to manage your cache expiry (if your cache store supports this option, which most do).
+
+  Album.cached_featured_albums(:expires_in => 1.day)
+  album.cached_top_tracks(:expires_in => 1.day)
+
+Or via the cache configuration,
+
+  Album.instance_caches(:expires_in => 1.day) do
+    top_tracks
+    featured_albums
+  end
+
+If you would like to be able to pass more options to your cache store (like <tt>:unless_exists</tt>, etc), just add them to the <tt>AridCache::CacheProxy::OPTIONS_FOR_CACHE</tt> class constant, for example
+
+  AridCache::CacheProxy::OPTIONS_FOR_CACHE.push(:raw, :unless_exist)
+
+== Extras
+
+=== Cached Counts
+
+AridCache gives you counts for free.  When a collection is stored in the cache
+AridCache stores the count as well so the next time you request the count it
+just takes a single read from the cache.
+
+To get the count just append <tt>_count</tt> to your <tt>cached_</tt> call.  For example, if we have a cache like <tt>album.cached_tracks</tt> we can get the count by calling,
+
+  album.cached_tracks        => returns an array of tracks
+  album.cached_tracks_count  => returns the count with a single read from the cache
+
+This is also supported for your non-ActiveRecord collections if the collection <tt>responds_to?(:count)</tt>.  For example,
+
+  album.cached_similar_genres       => returns ['Pop', 'Rock', 'Rockabilly']
+  album.cached_similar_genres_count => returns 3
+
+Sometimes you may want the collection count without loading and caching the collection itself.  AridCache is smart enough that if you only ask for a count it will only query for the count.  This is only possible if the return value of your method is a named scope or association proxy (since these are lazy-loaded unlike a call to <tt>find()</tt>).
+
+In the example above if we only ever call <tt>album.cached_tracks_count</tt>, only the count will be cached.  If we subsequently call <tt>album.cached_tracks</tt> the collection will be loaded and the IDs cached as per normal.
+
+Other methods for caching counts are provided for us by virtue of ActiveRecord's built-in methods and named scopes, for example,
+
+  Artist.cached_count  # takes advantage of the built-in method Artist.count
+
+=== Pagination
+
+AridCache supports pagination using WillPaginate.  If you are not changing the order of the cached collection the IDs are paginated in memory and only that page is selected from the database - directly from the target table, which is extremely fast.
+
+An advantage of using AridCache is that since we already have the size of the collection in the cache no query is required to set the <tt>:total_entries</tt> on the <tt>WillPaginate::Collection</tt>.
+
+To paginate just pass a <tt>:page</tt> option in your call to <tt>cached_</tt>.  If you don't pass a value for <tt>:per_page</tt> AridCache gets the value from <tt>Model.per_page</tt>, which is what <tt>WillPaginate</tt> uses.
+
+The supported pagination options are:
+  :page, :per_page, :total_entries, :finder
+
+Some examples of pagination:
+
+  User.cached_active(:page => 1, :per_page => 30)
+  User.cached_active(:page => 2)                  # uses User.per_page
+  user.cached_pets(:page => 1)                    # uses Pet.per_page
+
+If you want to paginate using a different ordering, pass an <tt>:order</tt> option.  Because the order is being changed AridCache cannot paginate in memory.  Instead, the cached IDs are passed to your <tt>Model.paginate</tt> method along with any other options and the database will order the collection, apply limits and offsets, etc.  Because the number of records the database deals with is limited, this is still much, much faster than ordering over the whole table.
+
+For example, the following queries will work:
+
+  user.cached_companies(:page => 1, :per_page => 3, :order => 'name DESC')
+  user.cached_companies(:page => 1, :per_page => 3, :order => 'name ASC')
+
+By specifying an <tt>:order</tt> option in our cached call we can get different "views" of the cached collection.  I think this a "good thing".  However, you need to be aware that in order to guarantee that the ordering you requested is the same as the order of the initial results (when the cache was primed), we have to order in the database.  This results in two queries being executed the first time you query the cache (one to prime it and the other to order and return the results).  If no order option is specified, we can skip the second query and do everything in memory.
+
+If you have an expensive cache and don't want that extra query, just define a new cache with your desired ordering and use that.  Make sure that the order of the initial results matches your desired ordering.  Building on the example above we could do:
+
+  User.instance_caches do
+    companies_asc do
+      companies(:order => 'name ASC')
+    end
+    companies_desc do
+      companies(:order => 'name DESC')
+    end
+  end
+  user.cached_companies_asc(:page => 1, :per_page => 3)
+  user.cached_companies_desc(:page => 1, :per_page => 3)
+
+
+=== Limit & Offset
+
+You apply <tt>:limit</tt> and <tt>:offset</tt> options in a similar manner to the <tt>:page</tt> and <tt>:per_page</tt> options.  The limit and offset will be applied in memory and only the resulting subset selected from the target table - unless you specify a new order.
+
+  user.cached_pets(:limit => 2, :include => :toys)
+  user.cached_pets(:limit => 2, :offset => 3, :include => :toys)
+  genre.cached_top_ten_tracks { cached_tracks(:limit => 10, :order => 'popularity DESC') }
+
+=== Other Options to <tt>find</tt>
+
+The supported options to <tt>find</tt> are:
+  :conditions, :include, :joins, :limit, :offset, :order,
+  :select, :readonly, :group, :having, :from, :lock
+
+You can pass options like <tt>:include</tt> (or any other valid <tt>find</tt> options) to augment the results of your cached query.  Just because all of the options are supported, does not mean it's a good idea to use them, though.  Take a look at your logs to see how AridCache is interacting with the cache and the database if you don't get the results you expect.
+
+For example, we could call:
+
+  User.cached_active(:page => 2, :per_page => 10, :include => :preferences)
+
+To return page two of the active users, with the <tt>preferences</tt> association eager-loaded for all the users.
+
+=== Accessing the cached IDs directly
+
+Sometimes you may want to access the cached list of record IDs without instantiating all the records.  This can be useful, for example, to determine if a particular track belongs to a user's favorite tracks.  If we have cached the list of favorite tracks, we just need to determine whether the track's ID appears in the cached list of IDs.
+
+The cached result is a <tt>AridCache::CacheProxy::Result</tt> and can be accessed by passing the <b><tt>:raw => true</tt></b> option in your cached call.  The <tt>AridCache::CacheProxy::Result</tt> is a type of <tt>Struct</tt> with methods to return the <tt>ids</tt>, <tt>count</tt> and <tt>klass</tt> of the cached records.
+
+Note that passing the <tt>:raw</tt> option to your cache store is not supported, because the AridCache option shares the same name.  If you really want to get the marshalled result from your cache you will have to use <tt>cache.read</tt>, manually passing in the AridCache key and <tt>:raw</tt> option.
+
+Usage example:
+
+  user = User.first
+  user.cached_favorite_tracks  => returns [#<Track:1>, #<Track:2>]
+  user.cached_favorite_tracks(:raw => true) => returns
+      {
+        :klass => "Track",  # stored as a string
+        :count => 1,
+          :ids => [1, 2]
+      }
+  user.cached_favorite_tracks(:raw => true).ids => returns [1, 2]
+
+The cache will be primed if it is empty, so you can be sure that it will always return a <tt>AridCache::CacheProxy::Result</tt>.
+
+In some circumstances - like when you are querying on a named scope - if you have only requested a count, only the count is computed, which means the ids array is <tt>nil</tt>.  When you call your cached method passing in <tt>:raw => true</tt> AridCache detects that the ids array has not yet been set, so in this case it will perform a query to seed the ids array before returning the result.  This can be seen in the following example:
+
+  class User
+    named_scope :guests, :conditions => { :account_type => ['guest'] }
+  end
+
+  User.cached_guests_count => returns 4
+  Rails.cache.read(User.arid_cache_key(:guests)) => returns
+    {
+      :klass => "User",
+      :count => 4,
+        :ids => nil                 # notice the ids array is nil in the cache
+    }
+  User.cached_guests(:raw => true) => returns
+    {
+      :klass => "User",
+      :count => 4,
+        :ids => [2, 235, 236, 237]  # the ids array is seeded before returning
+    }
+
+== Efficiency
+
+* AridCache intercepts calls to <tt>cached_</tt> methods using <tt>method_missing</tt> then defines those methods on your models as they are called, so they bypass method missing on subsequent calls.
+* In-memory pagination of cached collections speeds up your queries.  See _Pagination_.
+* If you only request a count AridCache will only select the count.  See <i>Cached Counts</i>.
+* If a collection has already been loaded, you get the count for free.  See <i>Cached Counts</i>.
+
+== Compatibility
+
+Tested on Ruby 1.8.6, 1.8.7, REE 1.8.7 and 1.9.1.
+Tested in Rails 2.3.* and Rails 3
+
+For Ruby < 1.8.7 you probably want to include the following to extend the Array class with a <tt>count</tt> method.  Otherwise your <tt>cached_<key>_count</tt> calls probably won't work:
+
+  Array.class_eval { alias count size }
+
+For Rails 3 for some reason AridCache is not being included into ActiveRecord, so add the following to an initializer to get around that:
+
+  AridCache.init_rails
+
+== Resources & Metrics
+
+
+* {RDoc}[http://rdoc.info/projects/kjvarga/arid_cache]
+* {GetCaliper Metrics}[http://getcaliper.com/caliper/project?repo=git%3A%2F%2Fgithub.com%2Fkjvarga%2Farid_cache.git]
+
+== Known Issues
+
+1. <b>Caches that contains duplicate records will only return unique records on subsequent calls</b>.  This is because of the way <tt>find</tt> works when selecting multiple ids.  For example, if your query returns <tt>[#<User id: 1>, #<User id: 1>, #<User id: 1>]</tt>, the IDs are cached as <tt>[1,1,1]</tt>.  On the next call to the cache we load the IDs using <tt>User.find_all_by_id([1,1,1])</tt> which returns <tt>[#<User id: 1>]</tt>, not <tt>[#<User id: 1>, #<User id: 1>, #<User id: 1>]</tt> as you might have expected.
+2. <b>You can't cache polymorphic arrays</b> e.g. [#<User id: 1>, #<Pet id: 5>] because it expects all ActiveRecords to be of the same class.  We could accept a <tt>:polymorphic => true</tt> option but I don't think this is a great idea because instantiating all the records would result in a lot of queries to the individual tables.
+
+== Contributors
+
+Contributions are welcome!  Please,
+
+* Fork the project.
+* Make your feature addition or bug fix.
+* Add tests for it (this is important so I don't break it in a future release).
+* Commit (don't mess with the Rakefile, version, or history).
+* Send me a pull request.
+
+
+==== Thank-you to these contributors to AridCache:
+
+* {Sutto}[http://github.com/Sutto]
+
+== Copyright
+
+Copyright (c) 2009 Karl Varga. See LICENSE for details.