coffee_table 0.2.1 → 0.2.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 0a500c15b47d59719b545a05f0202fff9520233c
-  data.tar.gz: 7e3af3f690eeea5312797da412e3cb240037fbf5
+  metadata.gz: e8f7ff652cc590e6c9a33a97628fa5f7c97be1ac
+  data.tar.gz: ee7d71355ae8cae5bbc822a7d8fb82c3a57e173c
 SHA512:
-  metadata.gz: 53e13c4b868600c6870af3468ced06ec976e5f89eccf29260b1b8f33a7fde61b64235e88760f1559ba97b13d6728065f3e2fe0331512afedefcca4c470465e3e
-  data.tar.gz: f2084d4c0b148073490192953eb32c188eefd8ede78e83a5ecb551aa53fcc70a729bbd2e8eede03543652964f1f486c40896a2004a0d6aad8f1f3208979bb756
+  metadata.gz: 289f04effa492d9d354f44bd624b6c65a3c7c9f7a7db502a540470a3978046587ea59692d6f49d979450a545e0a80a2d621dec469e62b069b090e78a493572fb
+  data.tar.gz: 7dff15d4cd9c9a800c1349947dbcbeb56fc85257723955c918ff7e27e36c37ac3f154b7f8475824145e1900b4a0c5ad743b64f3e25941cc170a4aaf10fc0e886

data/Gemfile.lock

@@ -11,7 +11,7 @@ GIT
 PATH
   remote: .
   specs:
-    coffee_table (0.1.3)
+    coffee_table (0.2.2)
       activesupport
       gzip
       redis

data/README.textile

@@ -5,10 +5,10 @@ h1. CoffeeTable v0.1.1
 !https://gemnasium.com/stewartmckee/coffee_table.png!
 !https://coveralls.io/repos/stewartmckee/coffee_table/badge.png?branch=master(Coverage Status)!:https://coveralls.io/r/stewartmckee/coffee_table
 
-h2. Intro 
-  
+h2. Intro
+
   CoffeeTable is a smart fragment caching gem that was born out of a frustration with the standard caching methods.  Maintaining the cache keys constantly was a headache and 'bet its a caching issue' was a phrase uttered way too much.  CoffeeTable was designed to take on the role of maintaining the cache keys for you, allowing you to concentrate on what is in the cache.  It works by maintaining a list of its keys in a known format and when expiry is required for an object it knows which ones to expire.  It also hopefully will be a perfromance boost for some cases where you are being overly cautious about clearing cache, a more targeted approach will improve performance.
-    
+
 h3. Installation
 
 h4. Using Rails/Bundler
@@ -38,11 +38,11 @@ Creates a new cache object.  You can pass options into this method to modify the
   * :ignore_code_changes defaults to false.  By default a md5 hash of the code in the block is included in the key, if you change the code, the key automatically invalidates.  This is to protect against code changes that won't be picked up due to the cache returning.
   * :compress_content defaults to true and sets whether large strings are compressed
   * :compress_min_size defaults to 10240, which is 10k any strings larger than this are compressed before being stored
-  
+  * :max_threads defaults to 28, if running in limited thread environment you can reduce this (eg Heroku)
 
 h4. fetch(initial_key, *related_objects, &block)
 
-This is the main caching method.  Pass into this method as a block the chunck of code you want cached.  The first parameter is your key for this data and is then followed by as many objects as are valid for this block of code.  You can even pass in arrays and they will be expanded.  The only requirement for the objects being passed in is that they respond to an 'id' method.  If the last parameter is a Hash, this will be used as per cache options.  These options can be used for expiry of cache. 
+This is the main caching method.  Pass into this method as a block the chunck of code you want cached.  The first parameter is your key for this data and is then followed by as many objects as are valid for this block of code.  You can even pass in arrays and they will be expanded.  The only requirement for the objects being passed in is that they respond to an 'id' method.  If the last parameter is a Hash, this will be used as per cache options.  These options can be used for expiry of cache.
 
 bc. user_details = @coffee_table.fetch(:user_detail, @user, :expiry => 600) do
   @user.get_expensive_user_details
@@ -85,5 +85,3 @@ bc. @coffee_table.expire_for(User)
 this would expire all keys that reference the user objects.
 
 The best practice for this is to be as specific as you can when creating the key.  Also creating more targeted cache items may be better in some situations than having one large cache fragment.
-
-

data/changelog.txt

@@ -1,3 +1,5 @@
+0.2.2
+  - added max_threads option due to limited thread environment in heroku
 
 0.1.3
   - added compression for string content over 10k in size, can be turned off and limit changed
@@ -10,8 +12,7 @@
   - refactored get_cache method to fetch
 
 0.1.0
-  
+
   - Started a change log
   - Added sourcify to md5 hash the contents of the block to remove issues around code changes not being used due to cache
   - Added a key class to handle key generation and management
-

data/lib/coffee_table/version.rb

@@ -1,3 +1,3 @@
 module CoffeeTable
-  VERSION = "0.2.1"
+  VERSION = "0.2.2"
 end

data/lib/coffee_table.rb

@@ -27,6 +27,7 @@ module CoffeeTable
       default_ignore_code_changes_to false
       default_compress_content_to true
       default_compress_min_size_to 10240
+      default_max_threads_to 28
 
       if @options.has_key?(:redis_url)
         @redis = Redis.new({:url => @options[:redis_url]})
@@ -35,7 +36,7 @@ module CoffeeTable
       end
       rufus_version = Gem::Version.new(Rufus::Scheduler::VERSION)
       if rufus_version >= Gem::Version.new('3.0.0')
-        @scheduler = Rufus::Scheduler.new
+        @scheduler = Rufus::Scheduler.new(:max_work_threads => @options[:max_threads])
       else
         @scheduler = Rufus::Scheduler.start_new
       end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: coffee_table
 version: !ruby/object:Gem::Version
-  version: 0.2.1
+  version: 0.2.2
 platform: ruby
 authors:
 - Stewart McKee
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2016-04-23 00:00:00.000000000 Z
+date: 2016-06-01 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rspec