The beauty of OrmLiteConfig.UpdateFilter is that it works will all built in update methods.
If I add custom extensions for all update methods, each developer must remember use the custom update methods over the built in SS update methods. All code must be refactored, or selectively refactored where the custom update is useful, it would appear to be a brittle solution, in my case at least.
Adding an ObsoleteAttribute to the original method would provide a good opportunity to explain why an overload exists.
Right whereas any new overloaded version would need to have a new, (unideal) and confusing name with an additional param that only applies dependent on which Update API that was called, deprecates everyone’s existing code and prompts them to upgrade (causing friction w/o benefit) all whilst maintaining additional complexity for calling parallel filter versions - all this for an unpopular feature that’s never been requested and would very rarely be used.
Basically an example of a feature that adds negative value: disruptive, unpopular, confusing and forces additional complexity.
It can’t be the same name, but does the same functionality, it no longer has parity with InsertFilter and has extra param which isn’t obvious when it will be populated and internally would require supporting duplicate parallel impls. Would be a very ugly addition.