Split the with_deferred_parent_expiration and with_deferred_parent_expiration #578
Conversation
…e the ActiveSupport Deprecation
|
Tested in my mac with the following version of
All is ✅ . |
| @@ -225,6 +269,10 @@ def fetch_multi(*keys) | |||
| def with_deferred_expiration | |||
| raise NestedDeferredCacheExpirationBlockError if Thread.current[:idc_deferred_expiration] | |||
|
|
|||
| if Thread.current[:idc_deferred_parent_expiration] | |||
There was a problem hiding this comment.
Why are we deprecating here? Shouldn't we raise if they are both used? Ie with a nested deffered exception?
| raise NestedDeferredParentBlockError if Thread.current[:idc_deferred_parent_expiration] | ||
|
|
||
| if Thread.current[:idc_deferred_expiration] | ||
| deprecator.deprecation_warning("`with_deferred_parent_expiration`") |
There was a problem hiding this comment.
This should raise, not just emit a deprecation. The two are not compatible right?
There was a problem hiding this comment.
We should just always emit this deprecation. It shouldn't be blocked by the deferred expiration flag?
There was a problem hiding this comment.
It's just a warning, so will not block. We don't want to raise errors here, because we want the two methods are compatible.
The with_deferred_expiration has already covered with_deferred_parent_expiration.
parentdeferred expiration: supported by both.childdeferred expiration: only supported bywith_deferred_parent_expiration.attributedeferred expiration: only supported bywith_deferred_parent_expiration.
There was a problem hiding this comment.
The two methods can be nested and used together as they are compatible. We don't need to raise and fail if they are used together. The warning here is just to cover the case in this unit test: https://github.com/Shopify/identity_cache/pull/578/files#diff-a5e1bbc9f7c7519a1e9bd0e04064c349f39bf6a6a4d029651461b87ef81dde1eR258-R290
There was a problem hiding this comment.
I think there are two separate things here.
Regarding the incompatibility, I had the same concern, @grcooper. @drinkbeer and I paired on it and the nesting should be compatible, as also evidenced by the tests.
If there is a scenario we are concerned about we should write a test for it.
However, I think we should just be deprecating the use of this method in all cases (rather than the gated warning) as we want to progress to a V2 where we remove this method and just have people use .with_deferred_expiration.
So:
- Always fire the deprecation notice for
.with_deferred_parent_expiration - Maintain compatibility between the two APIs for now
- Seek to remove this method as a breaking change at the earliest convenience
Thoughts?
There was a problem hiding this comment.
Ah ok, I was thinking that they were not compatible. It looks like that test proves that they are compatible though and are not duplicating work 👍
| raise NestedDeferredParentBlockError if Thread.current[:idc_deferred_parent_expiration] | ||
|
|
||
| if Thread.current[:idc_deferred_expiration] | ||
| deprecator.deprecation_warning("`with_deferred_parent_expiration`") |
There was a problem hiding this comment.
I think there are two separate things here.
Regarding the incompatibility, I had the same concern, @grcooper. @drinkbeer and I paired on it and the nesting should be compatible, as also evidenced by the tests.
If there is a scenario we are concerned about we should write a test for it.
However, I think we should just be deprecating the use of this method in all cases (rather than the gated warning) as we want to progress to a V2 where we remove this method and just have people use .with_deferred_expiration.
So:
- Always fire the deprecation notice for
.with_deferred_parent_expiration - Maintain compatibility between the two APIs for now
- Seek to remove this method as a breaking change at the earliest convenience
Thoughts?
Yah all of these points make sense to me 👍 I think always firing the deprecation notice would be good. |
Deprecation message (tested with ActiveRecord 7.0 and 7.2):
