4727 replace redis with solidcache #4929
Conversation
| @@ -1,6 +1,5 @@ | |||
| development: | |||
| adapter: redis | |||
| url: redis://localhost:6379/1 | |||
| adapter: async | |||
There was a problem hiding this comment.
Not sure why we were using redis in dev but async in staging/prod previously as the adapter for Action Cable.
I think we are only using Action Cable for turbo streams atm.
Note: async isn't recommended for production. So we may want to switch to the action cable postgres adapter, or to solid_cable at some point.
| default: &default | ||
| store_options: | ||
| # Cap age of oldest cache entry to fulfill retention policies | ||
| max_age: <%= 14.days.to_i %> |
There was a problem hiding this comment.
This max_age is the default if you don't set it. I don't think it matters at this point because the only caching we currently do for historical trends is updated every 24 hours.
But we can make it 30 or 60 days if preferred.
| password: <%= ENV["DIAPER_DB_PASSWORD"] %> | ||
| database: <%= ENV["DIAPER_DB_DATABASE"] %> | ||
| timeout: 5000 | ||
| cache: |
There was a problem hiding this comment.
If we're creating a separate database... that needs a script or migration to be run, correct?
There was a problem hiding this comment.
All I had to run (with my env set to production) was db:prepare and that created the solid cache database and created the cache table.
I haven't really looked into the inner workings of how the database is created and table schema loaded.
I assume the deployment process for production has a db:migrate step but i dont think that will be enough in this case. Will double check tomorrow
There was a problem hiding this comment.
Yea so db:prepare in this case creates the cache database and then loads the cache table from the new schema file db/cache_schema.rb. It would also run any pending migrations, but there aren't any for this new cache table, just the schema to load.
There was a problem hiding this comment.
@coalest can you look to see if we can use the same database instead of 2 different ones? I know the docs seem to favor a separate DB, but it would simplify migration if we could just create a table in the existing DB.
There was a problem hiding this comment.
Yea I believe using the same database should be fine. I will make that change.
There was a problem hiding this comment.
Fixed in 8b116b6.
All that will be needed for produciton is to run db:migrate. I tested this locally (with environment set to production) and caching is working as expected.
|
@coalest: Your PR |
Resolves #4727
Description
Removes dependency on redis, and configures solid_cache to use postgres as a cache store.
Type of change
How Has This Been Tested?
I've tested the app in production mode on my local computer, and confirmed that caching is still working.
This change wouldn't be caught by our test suite so we need to be careful.
Also
db:prepareneeds to run after this change is merged in production in order to create the caching table in postgres. If the cache schema isn't loaded, then we will get an error every time we try to access the cache store (like on the historical trends pages).