porpoise 0.9.2 → 0.9.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 70da1e3de3220160b8c00fd70a9d50337540f85f
-  data.tar.gz: 740fa453878aad9df5a2d2d8ae0c4c2404be01d7
+  metadata.gz: 1bb9742ea2691c9286a6d5c59087aa574220e30a
+  data.tar.gz: d35d5078dfa2725190f8298030c1d7aa3fcaf186
 SHA512:
-  metadata.gz: b4f729b64723691c68b499916fc8a42497d7bdc29b7ae7854a1636067400db9af6343cdd58efba06562a2d0aeaa94558931772a6d68a79c5dc6eb3515a8d5fdc
-  data.tar.gz: 1664af19bba339e78dd17fd58954661f266cc302407076c55a06eac238a2568540adbbe7b991ddcdd9f8d860bc5ccdc767e7b89c1b3947cee08c10d6a02c75ce
+  metadata.gz: a2fac198b35735804800e2c18e7cc0a9240fe78f2ad93f7300c3d2b9e3ffdfb446a7ea57134651f4cf04d7a4f5d133872590387718ddec1effa294b9dfc7884a
+  data.tar.gz: 9307bec54ebd9202dfa2a315a9930531b11ebe3562b2e0b98f5b495e9e66f322f6aa05324822f3ed14f1304cba2011ec1c3bd2b6b27d0b3a46c964f4563ccf51

data/README.md

@@ -6,7 +6,7 @@ Porpoise implements an additional cache backend for Ruby on Rails applications.
 
 ### Performance
 
-Redis outperforms this implementation by a long shot and I don't think I have to tell why. For an SQL based solution it still performs alright though. Besides, this thing integrates with Rails, uses ActiveRecord and all the bloat that comes with it. And altough a cache should help performance, cache read/write speed sometimes are not the problem. To prevent firing the same query when reading the same cache fragment over and over again, this thing comes with a short life in-memory cache to quickly return those items. In our situation, reading data was even faster than the Redis based solution.
+Redis outperforms this implementation and I don't think I have to tell why. For an SQL based solution it still performs alright though. By using a short living in-memory cache it actually comes close to a Redis based solution, at least in our setup. Besides, this thing integrates with Rails, uses ActiveRecord and all the bloat that comes with it. And although a cache should help performance, cache read/write speed sometimes are not the problem. To prevent firing the same query when reading the same cache fragment over and over again, this thing comes with a short life in-memory cache to quickly return those items. In our situation, reading data was even faster than the Redis based solution.
 
 ### Then why?
 

data/gemfiles/rails_3.gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: ..
   specs:
-    porpoise (0.9.1)
+    porpoise (0.9.2)
       activerecord (>= 3.2)
       activesupport (>= 3.2)
       rails (>= 3.2)

data/gemfiles/rails_4.gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: ..
   specs:
-    porpoise (0.9.1)
+    porpoise (0.9.2)
       activerecord (>= 3.2)
       activesupport (>= 3.2)
       rails (>= 3.2)

data/gemfiles/rails_5.gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: ..
   specs:
-    porpoise (0.9.1)
+    porpoise (0.9.2)
       activerecord (>= 3.2)
       activesupport (>= 3.2)
       rails (>= 3.2)

data/lib/active_support/cache/porpoise_store.rb

@@ -174,6 +174,9 @@ module ActiveSupport
       end
 
       def short_mem_del(name)
+        @slc ||= {}
+        @slt ||= {}
+        
         @slc.delete(name)
         @slt.delete(name)
       end

data/lib/porpoise/version.rb

@@ -1,3 +1,3 @@
 module Porpoise
-  VERSION = "0.9.2"
+  VERSION = "0.9.3"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: porpoise
 version: !ruby/object:Gem::Version
-  version: 0.9.2
+  version: 0.9.3
 platform: ruby
 authors:
 - Wessel van Heerde
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2017-10-07 00:00:00.000000000 Z
+date: 2017-11-30 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler