Clean-up Matcher / ResourceUpdatePreProcessor duality #1914
Assignees
Comments
metacosm
added a commit
that referenced
this issue
May 24, 2023
Note that the current implementation is flawed because custom ResourceUpdatePreProcessor should be registered to be found when attempting to use custom matching logic. See also #1914 for more details.
metacosm
added a commit
that referenced
this issue
May 24, 2023
* fix: clean-up unneeded matcher field * fix: restore backwards compatibility Note that the current implementation is flawed because custom ResourceUpdatePreProcessor should be registered to be found when attempting to use custom matching logic. See also #1914 for more details.
|
this is related to this issue: |
|
also related: #1907 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Both concepts are actually quite tied together because usually, if you cannot use the generic matching behavior, this means that you also cannot update the associated resources. This usually means that you need to implement
ResourceUpdatePreProcessorif you implementMatcher, for example, if your dependent needs to update the metadata, it probably also need to check whether the actual resource matches the desired one by examining the metadata. However, if you only implementMatcher, your dependent will use the default updating logic, which will only consider thespecpart. To fix that problem, you must also implementResourceUpdatePreProcessor. However, this makes things awkward because we now have amatchesmethod on that interface. We therefore need to unify bothMatcherandUpdaterinterfaces by recognising that both are linked and specific behavior in one usually requires specific behavior in the other. This work was started in #1786 but needs to be cleaned-up further.The text was updated successfully, but these errors were encountered: