-
Notifications
You must be signed in to change notification settings - Fork 11k
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
[10.x] Add the ability to re-resolve cache drivers #46203
Conversation
is Adding to an interface not a breaking change? |
We aren't changing any interfaces. |
yeah, I realized it later on. I read upside down. I'd suggest when resubmitting, don't use old branches with commits that you have undone in a later commit (or squash them), to avoid conversations like this. :) |
Just look at the Files changed, I mentioned that the PR should be squash merged. |
This is in fact a breaking change, changing the signature of a method is a breaking change |
I discussed that in the PR description in detail. I'm pretty sure PRs that change method visibility to Also, Laravel 10 is freshly released and sometimes there are small breaking changes early on in a version release when bugs that weren't caught before the release are being fixed. And as I wrote above, in the (very unlikely) scenario that someone extended this method and kept it |
Thanks! |
(Resubmission of #46202, opening this PR from my own repo this time)
We're working on improving our cache tenancy support in Tenancy for Laravel and one of the things we'd need would be the ability to re-resolve the drivers for cache stores.
Currently (in v3), we only support Redis since we use cache tags to scope cache for tenants.
In v4, we'd like to have driver-agnostic cache tenancy using prefixes. We already have all of the code written (and tested with a laravel/framework fork that includes the changes from this PR) so we'd only need this added in Laravel.
We experimented with several different implementations and this is the one that requires the least changes to Laravel. It essentially only makes one method public and adds a setter to
Illuminate\Cache\Repository
.The changes here could in theory be breaking if:
resolve()
method inIlluminate\Cache\Manager
and kept itprotected
setStore()
inIlluminate\Cache\Repository
. We tried to avoid this being a problem by making the method as predictable as possible, so it's a setter that does exactly what its name implies.I think both of these changes are very low-risk and easily fixable if anyone overrode these methods. We also avoided touching any contracts and only changed the default classes that implement them.
(Please squash when merging)