-
Notifications
You must be signed in to change notification settings - Fork 831
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switching to a db name instead of just a store name #1184
Conversation
Changes Unknown when pulling 176ced6 on cache-expiration-db-name into ** on v3**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That general change seems fine, but are there any considerations necessary to account for developers migrating from either v2 or an older v3 alpha?
If this will just cause those developers to "start fresh" with an empty set of cache expiration data, I think that's fine, but I just wanted to make sure that there isn't the potential to end up with runtime exceptions in that scenario.
@jeffposnick I've bumped the version number and added tests to handle a version change. (Also got coverage to 100%). |
PR-Bot Size PluginChanged File Sizes
New FilesNo new files have been added. All File SizesView Table
Workbox Aggregate Size Plugin☠️ WARNING ☠️We are using 154% of our max size budget. Total Size: 22.53KB Gzipped: 9.02KB |
Changes Unknown when pulling 2e32fd6 on cache-expiration-db-name into ** on v3**. |
R: @jeffposnick @philipwalton
Previously I was using a single database name with multiple store names for the cache expiration timestamps,. This doesn't work / make sense given that you need to know the store names up front which for multiple instances of the class - will not be the case.
This change moves to using a name for the database and store name to ensure uniqueness.
Fixes #1175