internal static void UpdateOnlySql<T>(this IDbCommand dbCmd, T model, SqlExpression<T> onlyFields)
{
if (OrmLiteConfig.UpdateFilter != null)
OrmLiteConfig.UpdateFilter(dbCmd, (object) model);
IList<string> list = onlyFields.UpdateFields.Count == 0 ? onlyFields.GetAllFields() : (IList<string>) onlyFields.UpdateFields;
Would you be able to add an additional OrmLiteConfig.UpdateFilter that includes the list of fields that will be updated?
(I can’t add to user voice, so asking here)
No, having multiple UpdateFilter overloads would be confusing and modifying the existing signature would be a breaking change.
I’d recommend creating your own high-level custom extension Update extension method that runs whatever custom logic you need before calling into OrmLite.
Okay, that could work.
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.
I wouldn’t agree that the name has to be confusing or that an upgrade should be forced, the rest, yes.
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.
Agree, it would be ugly.