[11.x] Add DeleteWhenMissingModels attribute #50890
Merged
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.
Idea behind this PR
This PR offers an alternative to defining the "magic"
deleteWhenMissingModels
. I often struggle to rememberthe name of this property. I either look through the framework code or look up documentation. I believe
attributes provide a better way to define these side effects. And IDEs can autocomplete them more easily.
Before:
After:
Breaking changes
None come to mind.
Personal suggestion
I personally feel the
deleteWhenMissingModels
property should be removed in the future in favor of thisattribute. I don't think it makes sense to maintain two approaches to do this. I guess this would look like
a deprecation in 12.x and removal in 13.x? As there is no way to deprecate something that isn't defined
in the framework itself but only referenced, I think a note in the upgrade guide would have to be enough.
A slight breaking change when switching over from the property to the attribute would be that attributes
are not inherited along with classes (jobs) themselves. So if you extend a job with the
deleteWhenMissingModels
property and that gets replaced by the attribute it would break the behaviour of the "child job".
That might be worth noting in the docs
Docs
If this PR gets merged I think it should also be reflected in the documentation. I will create a PR there as well.