Add #cache_key to ActiveRecord::Relation. #20884

afcapel · 2015-07-14T23:00:42Z

The Rails caching guide suggests to create a cache key for collections of objects using the collection size and the timestamp of the last updated record. We could automate the process baking this logic into ActiveRecord::Relation.

    @users = User.where("name like ?", "%Alberto%")
    @users.cache_key
    => "/users/query-5942b155a43b139f2471b872ac54251f-3-20150714212107656125000"

The end result is that you can have cache keys in any relationship that will expire when the any of records matching the relation query changes.

egilburg · 2015-07-14T23:08:39Z

activerecord/lib/active_record/relation.rb

+    #
+    #   Product.where("name like ?", "%Game%").cache_key(:last_reviewed_at)
+    def cache_key(timestamp_column = :updated_at)
+      query_signature = Digest::MD5.hexdigest(to_sql)


Perhaps use SHA over MD5?

The logic select count(*), max(updated_at) could be written manually to only need one sql statement.

What if table has no updated_at column?

Do we need to expose internal logic of sql+count+updated? If not, we could use a single hash function (Digest::SHA1("#{to_sql}-#{count}-#{timestamp}")) and have a shorter string to return.

@egilburg thanks for your feedback, here are my thoughts:

Although MD5 can have some issues for cryptography I think it is fine for fingerprinting. It's somewhat less CPU intensive and it's what the Asset Pipeline uses for fingerprints.

That's a good idea, although I'll have to check if I can create the query in a DB independent manner.

It will fail hard with an missing column exception. I think that's the right behaviour.

The string length it's not an issue, AFAICT. Average key length ~ 75 chars (depending on the model name), while memcached keys can be up to 255 chars. I'd prefer to optimise for the readability of the key.

If used in client side query/HTML source code, this will leak total record count of whole db table which may be privacy issue in multi tenant systems.

Presumably it'd only leak the count of the query you're displaying, which would be scoped to the tennant.

egilburg · 2015-07-14T23:14:27Z

I also guess it doesn't detect changes on includes tables, right? Probably good idea to document that caveat.

afcapel · 2015-07-15T22:49:25Z

@egilburg again, I'm trying to follow the same patterns as ActiveRecord::Base#cache_key which won't change automatically when a dependent record changes, unless you make that record to touch the parent object. You need to understand the principles of Russian doll caching, but I think that explanation belongs in the Rails caching guide, not in this particular method documentation.

sgrif · 2015-07-17T23:45:13Z

activerecord/lib/active_record/relation.rb

+    #
+    # Under the hood this triggers two SQL queries:
+    #
+    #    SELECT COUNT(*) FROM "products" WHERE (name like '%Cosmic Encounter%')


Why is this query needed? Is there any case in which the count can change, without the updated_at of the newest record changing? (Aside from deliberately bypassing this?)

@sgrif if you delete a record other than the last one, the collection will change but the newest updated_at will be the same.

Ah, right. We should still condense this down to a single query though (and change COUNT(*) to COUNT(updated_at) so we only need to access a single column.

@sgrif That makes sense, I'll prepare the change.

COUNT(updated_at) actually needs to read all the values for that column... COUNT(*) only counts the rows, so it does not.

bogdan · 2015-07-18T06:19:05Z

This method requires an index on updated_at column. This requirement makes it sometimes unusable if table is large enough. This feature is definitely unusable in my project.

I am not sure if rails can include such features. You may relay on it when your DB is small but in a 1-2 year you should make it more smart or chose other caching strategy.

sgrif · 2015-07-18T11:00:53Z

That's a fair concern. This method is completely unoverrideable as defined. Perhaps it should delegate to a class method that the users can override as desired.

sgrif · 2015-07-18T12:23:58Z

I'd also like to see some more thorough tests for this behavior. Asserting that the hash of the query does change based on the SQL performed (maybe asserting that WHERE 1=1 changes the cache key). I'd also like to see explicit tests for the count portion, with and without a scope to ensure it matches that of the relation.

afcapel · 2015-07-18T12:32:08Z

@bogdan I don't see how that is different from any AR method querying a column other than id, for instance User.where(email: "..."). You have to add indexes to columns in big tables that you are going to scan, but that concern is left to the developer, as it depends on many factors that rails can not foresee.

sgrif · 2015-07-18T12:47:17Z

@afcapel Regardless, the user needs to be able to change this behavior if they desire. We shouldn't be locking them into one implementation, the same way as they can override it for a single value. I think the simplest solution is to have the method be ActiveRecord::Base.collection_cache_key(collection, timestamp_column = :updated_at) and have the implementation on Relation be nothing more than

def cache_key(timestamp_column = :updated_at)
  @klass.collection_cache_key(self, timestamp_column)
end

afcapel · 2015-07-18T16:58:16Z

@sgrif I've updated the PR with your feedback, moving collection_cache_key to AR::Base, adding more tests around the query cache and ensuring only a query is triggered. Please, let me know what you think.

sgrif · 2015-07-18T17:13:30Z

I have some more comments but I'm traveling the rest of the day, will comment further tonight.

sgrif · 2015-07-19T22:01:12Z

activerecord/lib/active_record/collection_cache_key.rb

+      size, timestamp = if collection.loaded?
+        [collection.size, collection.collect(&timestamp_column).compact.max]
+      else
+        column_type = collection.klass.type_for_attribute(timestamp_column.to_s)


collection.klass is always self

Not in cases in which you call ActiveRecord::Base.collection_cache_key(collection) like this one. It's a bit annoying, but since a class method is public I think we need to support that kind of calls.

I do not think we should support calling this method in any case other than a relation calling this method on self.klass

In fact, I would even go so far as to say it's worth mentioning you should not call this method directly in the documentation.

sgrif · 2015-07-20T00:07:04Z

@afcapel Did you exclude the suggestion about changing collection.klass to implicit self + documenting "this method should not be called directly" because you feel strongly against that suggestion? It's completely fine if that's the case, I would just like to confirm that you feel strongly that is not the right direction to go, and not an oversight.

In either case, can you either implement that suggestion, or confirm you feel strongly it is incorrect, and then squash & rebase?

sgrif · 2015-07-20T00:11:50Z

activerecord/lib/active_record/relation.rb

+    # You can also pass a custom timestamp column to fetch the timestamp of the
+    # last updated record.
+    #
+    #   Product.where("name like ?", "%Game%").cache_key(:last_reviewed_at)


We need to document that the user can override this behavior by implementing self.collection_cache_key on the class

afcapel · 2015-07-20T00:11:57Z

@sgrif oh, no I just missed the comments, but I think it's a good idea to make that method as "private" as possible. I'll make the change, squash and rebase.

sgrif · 2015-07-20T00:12:23Z

activerecord/lib/active_record/collection_cache_key.rb

+
+    # Generates a cache key for the records in the given collection.
+    # See <tt>ActiveRecord::Relation#cache_key</tt> for details.
+    def collection_cache_key(collection = all, timestamp_column = :updated_at)


I would actually prefer to mark this method as # :nodoc: since it only serves as a hook for Relation#cache_key

sgrif · 2015-07-20T00:13:21Z

❤️ I just left 2 more comments about docs, besides that, this is good to merge. Ping me once updated. (The wife wants to head to the movies so I might not get to it tonight)

afcapel · 2015-07-20T00:58:56Z

@sgrif nice, the PR is already updated. Thanks for your help!

egilburg · 2015-07-20T01:47:00Z

activerecord/lib/active_record/relation.rb

+    #
+    # You can customize the strategy to generate the key on a per model basis
+    # overriding ActiveRecord::Base#collection_cache_key.
+    def cache_key(timestamp_column = :updated_at)


for clarity perhaps rename timestamp_column to cache_key_column. For example tables without timestamp but which have autosequence id could use the id column, by defining:

def cache_key super(:id) end

On other hand this would introduce discrepancy between definition of collection_cache_key. So another alternative would be to extract class method cache_key_column which returns :updated_at by default and which user could override.

Sorry, I'm not sure if cache_key_column is a better name. To me def cache_key(cache_key_column) sounds like we will fetch the key from a column, which is not exactly right.

afcapel · 2015-07-31T09:39:03Z

@sgrif any updates on this? Please let me know if you think it needs any more changes.

Add #cache_key to ActiveRecord::Relation.

PostgreSQL is strict about the usage of `DISTINCT` and `ORDER BY`, which one of the tests demonstrated. The order clause is never going to be relevant in the query we're performing, so let's just remove it entirely.

swalkinshaw · 2015-08-08T04:28:24Z

@afcapel before I created a new issue I just want to bring up a potential problem here.

Right now the cache key is a combination of 3 factors: a) SQL query digest, b) record count, c) max timestamp. This does cover most situations but there's a few where it doesn't. The easiest use case to explain it is any query involving limit.

Pseudo query: Post.order(:title).limit(5). Let's say the 5 records returned are:

[
  { title: 'A', updated_at: 2015-08-04 04:14:42 +0000 },
  { title: 'B', updated_at: 2015-08-05 04:14:42 +0000 },
  { title: 'C', updated_at: 2015-08-08 04:14:42 +0000 },
  { title: 'D', updated_at: 2015-08-04 04:14:42 +0000 },
  { title: 'E', updated_at: 2015-08-05 04:14:42 +0000 }
]

Now let's delete the post with title 'B' and re-run the query Post.order(:title).limit(5):

[
  { title: 'A', updated_at: 2015-08-04 04:14:42 +0000 },
  { title: 'C', updated_at: 2015-08-08 04:14:42 +0000 },
  { title: 'D', updated_at: 2015-08-04 04:14:42 +0000 },
  { title: 'E', updated_at: 2015-08-05 04:14:42 +0000 },
  { title: 'F', updated_at: 2015-08-05 04:14:42 +0000 }
]

Notice that the 3 factors of the cache key all remain the same.

a) same query digest
b) same count of 5
c) same max updated_at (the newest one is still there)

We ran into this issue implementing relation cache keys in our app we found the only reliable solution was to add a 4th factor: a representation of all the relation's id attributes.

In Postgres we accomplished it using md5(array_agg(id || '-' || updated_at)::text) for non-loaded queries. And for already loaded ones:

results = collection.flat_map { |item| [item.id, item.updated_at].join('-') }
Digest::SHA1.hexdigest(results.join)

You'll also note we also just skipped only taking the max updated_at and just used them all just like we did with id.

manuelmeurer · 2015-08-19T16:35:27Z

I agree with @swalkinshaw, ran into the same situation where max updated_at, collection size and SQL query digest are not "sufficiently unique".

christos · 2015-09-04T22:12:02Z

I've had the same issues as @swalkinshaw and @manuelmeurer using this approach. I've created PR #21503 with a more complete solution similar to @swalkinshaw. See the PR description for more details.

Assuming we are correct @sgrif, If this PR goes in to Rails 5, it could cause a lot of cache debugging headaches to people. Can you either review #21053 or revert this PR?

Rails has its own #cache_key implementation for collections introduced in Rails 5: rails/rails#20884 The key is different and not tuned to postgresql, but allows us to drop extra code/patches.

egilburg reviewed Jul 14, 2015
View reviewed changes

sgrif reviewed Jul 17, 2015
View reviewed changes

sgrif reviewed Jul 19, 2015
View reviewed changes

sgrif reviewed Jul 20, 2015
View reviewed changes

Add #cache_key to ActiveRecord::Relation.

476e3f5

afcapel force-pushed the ar-relation-cache-key branch from e1120a7 to 476e3f5 Compare July 20, 2015 00:48

egilburg reviewed Jul 20, 2015
View reviewed changes

sgrif merged commit 476e3f5 into rails:master Aug 2, 2015

sgrif added a commit that referenced this pull request Aug 2, 2015

Merge pull request #20884

cc10911

Add #cache_key to ActiveRecord::Relation.

robin850 mentioned this pull request Aug 11, 2015

[Meta] Rails 5.0 Release Notes #20612

Closed

christos mentioned this pull request Sep 4, 2015

Use collection ids and timestamps to generate truly unique collection cache keys #21503

Closed

metaskills mentioned this pull request Mar 21, 2016

Gem version 0.1.0 customink/activerecord-collection_cache_key#1

Merged

This was referenced Dec 10, 2016

Caching woes since #20884 #27326

Closed

collection_cache_key now respects limit() #27331

Closed

javan mentioned this pull request Jan 4, 2017

ActiveRecord::Relation#cache_key returns same key for different records with hm:t association #27570

Open

alipman88 mentioned this pull request Dec 23, 2019

Add first & last_id segments to collection cache_version #37724

Open

Add #cache_key to ActiveRecord::Relation. #20884

Add #cache_key to ActiveRecord::Relation. #20884

Uh oh!

Conversation

afcapel commented Jul 14, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

egilburg commented Jul 14, 2015

Uh oh!

afcapel commented Jul 15, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bogdan commented Jul 18, 2015

Uh oh!

sgrif commented Jul 18, 2015

Uh oh!

sgrif commented Jul 18, 2015

Uh oh!

afcapel commented Jul 18, 2015

Uh oh!

sgrif commented Jul 18, 2015

Uh oh!

afcapel commented Jul 18, 2015

Uh oh!

sgrif commented Jul 18, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgrif commented Jul 20, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

afcapel commented Jul 20, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sgrif commented Jul 20, 2015

Uh oh!

afcapel commented Jul 20, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

afcapel commented Jul 31, 2015

Uh oh!

swalkinshaw commented Aug 8, 2015

Uh oh!

manuelmeurer commented Aug 19, 2015

Uh oh!

christos commented Sep 4, 2015

Uh oh!

Uh oh!