-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always use TypeHandler for parameters if available #177
Conversation
Previously TypeHandlers could override the logic for built-in SQL data types (int, byte, DateTime, etc.) when they were return values via ITypeHandler.Parse, but ITypeHandler.SetValue was never called for these types when used as parameters. Moved the typeHandlers.TryGetValue() call up to make sure a type handler is always used if available.
Allow passing an IDictionary<string, object> as parameter object
Previously TypeHandlers could override the logic for built-in SQL data types (int, byte, DateTime, etc.) when they were return values via ITypeHandler.Parse, but ITypeHandler.SetValue was never called for these types when used as parameters. Moved the typeHandlers.TryGetValue() call up to make sure a type handler is always used if available.
Conflicts: Tests/Tests.cs
I have applied changes from this PR on the latest master, and it works like a charm for me. |
It would be great if this fix could get in. I guess there is not many conflicts to resolve, right? |
I would imagine not if you were able to simply apply the changes to the current master, however even then it is still a matter of Marc's time, since he needs to verify the PR before merging. |
Do you mind rebasing this to current master so we can take a proper look and merge it in? |
Sure, I'll have a look this evening. |
It looks like we can't actually pull this in due to comments mentioned on #339. It'll require some more digging to see if we can do this in a workable way - punting for the moment while we do some maintenance to make all future PRs easier though. |
In #339 (comment):
However, both issues are now closed despite not being resolved; @NickCraver consider reopening. |
Previously TypeHandlers could override the logic for built-in SQL data
types (int, byte, DateTime, etc.) when they were return values via
ITypeHandler.Parse, but ITypeHandler.SetValue was never called for these
types when used as parameters. Moved the typeHandlers.TryGetValue() call
up to make sure a type handler is always used if available.
Added tests to confirm standard behaviour is still working, and that ITypeHandler.SetValue is now called for built-in types.