Clear Rails cache when upgrading Consul Democracy #5547
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
javierm
force-pushed
the
empty_cache_when_upgrading
branch
2 times, most recently
from
2514132
to
e9be45e
Compare
We use caching in our application in two different ways: 1. Rails.cache.fetch in models/controllers/libraries 2. Fragment caching in the views When using Rails.cache.fetch, we usually set an expiration date or provide a precise way to invalidate it. If the code changes and the information stored in the cache is different from what the new code would return, it's usually not a big deal because the cache will expire in an hour or a day. Until commit <insert_commit_here>, the statistics were an exception to this rule, but that's no longer the case. The actual exception to this rule are the i18n translations, but the code caching them is very simple and hasn't changed for more than three years (when it was written for the first time). When using fragment caching, on the other hand, Rails automatically invalidates the cache when the associated _view code_ changes. That is, if a view contains cache, the view renders a partial, and the partial changes, the cache is correctly invalidated. The cache isn't invalidated when the code in helpers, models or controllers change, though, which the Rails team considers a compromise solution. However, we've been moving view partials (and even views) to components, and the cache isn't invalidated when a component changes (it doesn't matter whether the component Ruby file or the component ERB file changes). That means that the cache will keep rendering the HTML generated by the old code. So, now, we're clearing the cache when upgrading to a new version of Consul Democracy, as part of the release tasks. That way, institutions upgrading to a new version don't have to worry about possible issues with the cache due to the new code not being executed. I was thinking of adding it to a Capistrano task, but that would mean that every time people deploy new code, even if it's a hotfix that doesn't affect the cache at all, the cache would be cleared, which could be inconvenient. Doing it in a release, that usually changes thousands of lines of code, sounds like a good compromise.
javierm
force-pushed
the
empty_cache_when_upgrading
branch
from
e9be45e
to
bd56eb9
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
References
Background
We use caching in our application in two different ways:
When using Rails.cache.fetch, we usually set an expiration date or provide a precise way to invalidate it. If the code changes and the information stored in the cache is different from what the new code would return, it's usually not a big deal because the cache will expire in an hour or a day. Until commit a4461a1, the statistics were an exception to this rule, but that's no longer the case. The actual exception to this rule are the i18n translations, but the code caching them is very simple and hasn't changed for more than three years (when it was written for the first time).
When using fragment caching, on the other hand, Rails automatically invalidates the cache when the associated view code changes. That is, if a view contains cache, the view renders a partial, and the partial changes, the cache is correctly invalidated. The cache isn't invalidated when the code in helpers, models or controllers change, though, which the Rails team considers a compromise solution.
However, we've been moving view partials (and even views) to components, and the cache isn't invalidated when a component changes (it doesn't matter whether the component Ruby file or the component ERB file changes). That means that the cache will keep rendering the HTML generated by the old code.
Objectives
Notes
I was thinking of adding it to a Capistrano task, but that would mean that every time people deploy new code, even if it's a hotfix that doesn't affect the cache at all, the cache would be cleared, which could be inconvenient. Doing it in a release, that usually changes thousands of lines of code, sounds like a good compromise.