Unuse ActiveRecord::Base#cache_key #8185
Conversation
| @@ -42,7 +42,7 @@ def show | |||
| format.json do | |||
| skip_session! | |||
|
|
|||
| render_cached_json(['activitypub', 'actor', @account.cache_key], content_type: 'application/activity+json') do | |||
| render_cached_json(['activitypub', 'actor', @account], content_type: 'application/activity+json') do | |||
There was a problem hiding this comment.
If an array is given to the key of Rails.cache.fetch, the key will be like activitypub/actor/accounts/1.
| @@ -17,7 +17,7 @@ class Api::V1::StatusesController < Api::BaseController | |||
| CONTEXT_LIMIT = 4_096 | |||
|
|
|||
| def show | |||
| cached = Rails.cache.read(@status.cache_key) | |||
| cached = Rails.cache.read(@status) | |||
There was a problem hiding this comment.
It is not related to this PR, but the cached account information may be old ...
|
Could you explain the significance of these changes? I do not understand |
|
When cache_versioning is true from Rails 5.2 cache_key no longer includes the value of updated_at, and version information such as the value of updated_at is now managed by ActiveSupport::Cache::Store. There is an advantage that the number of keys increases for each version, and wasteful caching is not created. reference: rails/rails#29092 |
|
@abcang How does this PR interact with the statuses/statuses_stats separation? Currently we fetch updated_at from statuses_stats if it's more recent. But if we won't use updated_at, then updates on StatusStat need to bump the Status' cache version |
|
When cache_collection is used, since updated_at of statuses_stats is read by Status.cache_ids, it works correctly. I think that it will not work properly if Status.cache_ids is not used. Also, since json which is used for ActivityPub does not use information of statuses_stats, it seems no problem. |
* Unuse ActiveRecord::Base#cache_key * Enable cache_versioning * Call cache_collection
Fix #8711 Media attachments are generally immutable, but admins can update the sensitive flag, and this would ensure the change is visible instantly. Same for updates to status stats. That is a regression from #8185, because even the correct updated_at fetched from a join doesn't seem to invalidate the cache.
* Reset status cache when status_stat or media_attachment updates Fix #8711 Media attachments are generally immutable, but admins can update the sensitive flag, and this would ensure the change is visible instantly. Same for updates to status stats. That is a regression from #8185, because even the correct updated_at fetched from a join doesn't seem to invalidate the cache. * Remove join from Status#cache_ids since it has no effect
Change to give the instance key instead of cache_key to the key of the cache. Rails automatically processes the version information by specifying the instance as a key.