pg_cache_key 0.1.5 → 0.1.6

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: e77a9f091922442dc6b19d2015d53e1e7bf93ece
-  data.tar.gz: 339813b6a21d0b8de74412de8b62567ad341ab3e
+  metadata.gz: 995d11055ccb51441104752165aa4d6e98822cbe
+  data.tar.gz: d4dd6e20765a25e16a04eb124a437ec83fc3bf35
 SHA512:
-  metadata.gz: 930b14dc2c3545747b6209db0f378d403eb3a695b04de241ac6e934d5483636db09c6fb8bb109986bc918dd9c0782d8adc3a0e063848c63184662b5e93a4e448
-  data.tar.gz: 20bf20ebcda951fae3d0e5107bbd08de7e2a10c7be761daccbdf2f12c9ddaeeba91ecb16177bd2980658da9c60e6697a1358fe35842e19a6b65f7ba844535410
+  metadata.gz: '02802c91e0378b83668dd11854a425fdcd96244c50e9be3f68ba59140ebc4b21998d9ad2722233709b387d84b7a5b0f4a0d796d88643348ca136ee4c34618bfe'
+  data.tar.gz: 945a514b98459e782d6e34cd6c5a8a90e94735d948c4789dd271edca462c6551e78b7e73c17bfb74bfe6b7a86ed5f0e3a9e19aaa360bae5408fb87ea076677e7

data/README.md

@@ -42,6 +42,22 @@ without includes: 10 items in collection ~ x1.2 faster, 20 ~ x1.25, 50 ~ x1.5, 1
 
 with includes: 10 items in collection ~ x3.6 faster, 20 ~ x4, 50 ~ x5.6, 1000 ~ x32
 
+Benchmark code can look like this:
+
+```ruby
+def cache_key_vs_db_checksum(n, model_or_relation = Request)
+      Benchmark.ips do |bm|
+
+        bm.report(:direct_cache_key_rnd) {  ApplicationController.new.fragment_cache_key( model_or_relation.limit(n).random().old_cache_key ) ; :done }
+        bm.report(:checksummed_cache_key_rnd ) { ApplicationController.new.fragment_cache_key( model_or_relation.limit(n).random().new_cash_key ); :done }
+
+        bm.compare!
+      end
+
+    end
+```
+Rem: since gem replaces cache_key, this code will need some changes to benchmark on your machine 
+
 Of course this is not the numbers for whole page rendering, but it's noticeable. 
 
 One of my real page goes from 0.8+ sec, for largest available pagination, to 0.6 sec per page 
@@ -72,9 +88,12 @@ It works out of the box.
 По идее работает само из коробки, но если будут траблы - пишите.
 
 ## Testing
+rake spec
+
 Tested only query string for simple case. In your project you may test it on more specific query. 
 
 ## Testing(рус)
+rake spec 
 Тестируется только строка запроса для самого простого случая + добавление метода в активрекорд релейшен. 
 Стабильность на сложных запросах специфических для вашего приложения можете добавить в свои тесты.
 

data/lib/pg_cache_key/version.rb

@@ -1,3 +1,3 @@
 module PgCacheKey
-  VERSION = "0.1.5"
+  VERSION = "0.1.6"
 end

data/lib/pg_cache_key.rb

@@ -1,24 +1,14 @@
 require "pg_cache_key/version"
 
-# In rails 5 it can be
-# module ActiveRecord
-#   module CollectionCacheKey
-#     def collection_cache_key(collection = all, timestamp_column = :updated_at) # :nodoc:
-#       # why use connection.execute instead of doing collection.select because of an order. if you using some order on your scope
-#       # then columns you using to order must appear in the GROUP BY clause or be used in an aggregate function or you will get an error
-#       cache_columns = [timestamp_column, :id]
-#       @cache_keys ||= {}
-#       # we need to add select cache_columns explicitly because if relation has includes it might transform columns to aliases
-#       @cache_keys[timestamp_column] ||= connection.execute( "SELECT md5(string_agg( #{cache_columns.map{|fld| "\"t\".\"#{fld}\"::text" }.join('||')}, '') ) as cache_key
-#                             FROM (#{ collection.select(cache_columns).try(:to_sql) }) t" )[0]['cache_key']
-#     end
-#   end
-# end
-
 module PgCacheKey
   def cache_key_raw_sql( timestamp_column = :updated_at )
-    "SELECT md5(string_agg( t.ckc_#{timestamp_column}||t.ckc_id, '') ) as cache_key \
-FROM (#{ select( [timestamp_column, :id].map{|ckc| "#{table_name}.#{ckc}::text as ckc_#{ckc}" } ).try(:to_sql) }) t"
+    # Rem 1: why use connection.execute instead of doing collection.select because of an order. if you using some order on your scope
+    # then columns you using to order must appear in the GROUP BY clause or be used in an aggregate function or you will get an error
+    # Rem 2: we need to add select( cache_columns ) explicitly because if relation include it might transform columns to aliases
+    # and we must also select them as uniq-aliase so PG wouldn't be confused
+    # 'ckc' means cache key column :)
+    "SELECT md5(string_agg( t.ckc_#{timestamp_column}||t.ckc_id, '') ) as cache_key FROM (#{
+      select( [timestamp_column, :id].map{|ckc| "#{table_name}.#{ckc}::text as ckc_#{ckc}" } ).try(:to_sql) }) t"
   end
 end
 
@@ -40,12 +30,8 @@ module ActiveRecord
     include PgCacheKey
 
     def cache_key(timestamp_column = :updated_at)
+      return "#{self.class.to_s.underscore}/blank" if blank?
       @cache_keys ||= {}
-      # Rem 1: why use connection.execute instead of doing collection.select because of an order. if you using some order on your scope
-      # then columns you using to order must appear in the GROUP BY clause or be used in an aggregate function or you will get an error
-      # Rem 2: we need to add select( cache_columns ) explicitly because if relation has includes it might transform columns to aliases
-      # and we must also select them as uniq-aliase so PG wouldn't be confused
-      # 'ckc' means cache key column :)
       @cache_keys[timestamp_column] ||= connection.execute( cache_key_raw_sql(timestamp_column) )[0]['cache_key']
     end
 

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: pg_cache_key
 version: !ruby/object:Gem::Version
-  version: 0.1.5
+  version: 0.1.6
 platform: ruby
 authors:
 - alekseyl
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2016-09-26 00:00:00.000000000 Z
+date: 2017-06-29 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -133,7 +133,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.5.1
+rubygems_version: 2.6.8
 signing_key: 
 specification_version: 4
 summary: collection_cache_key replacement for system which uses PG as DB