-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
DbContext: ExecuteSqlCommand has poor usability when used with params and cancellation tokens #7100
Labels
breaking-change
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-bug
Milestone
Comments
We should look at adopting the pattern we use elsewhere for async methods (not combining |
ajcvickers
added a commit
that referenced
this issue
Jan 25, 2017
Issue #7100 Allow: - Async without explicit cancellation token - Strongly typed arrays/lists - Not accidentally passing cancellation token as parameter There is no overload taking `IEnumerable<TParam>` because this results in a single string parameter being passed as `IEnumerbale<char>`. A similar situation still exists for parameters that implement IList of something, but this seems much less likely. Another option would be to add an explicit overload that takes string and revert to IEnumerable, but this would only cover the string case and not any other parameter type that implements IEnumerable.
ajcvickers
added a commit
that referenced
this issue
Jan 25, 2017
Issue #7100 Allow: - Async without explicit cancellation token - Strongly typed arrays/lists - Not accidentally passing cancellation token as parameter There is no overload taking `IEnumerable<TParam>` because this results in a single string parameter being passed as `IEnumerbale<char>`. A similar situation still exists for parameters that implement IList of something, but this seems much less likely. Another option would be to add an explicit overload that takes string and revert to IEnumerable, but this would only cover the string case and not any other parameter type that implements IEnumerable.
ajcvickers
added a commit
that referenced
this issue
Jan 26, 2017
Issue #7100 Allow: - Async without explicit cancellation token - Not accidentally passing cancellation token as parameter - Allow IEnumerables
ajcvickers
added a commit
that referenced
this issue
Jan 26, 2017
Issue #7100 Allow: - Async without explicit cancellation token - Not accidentally passing cancellation token as parameter - Allow IEnumerables
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
breaking-change
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-bug
We crash because the parameters object[] ends up with a single int[] element.
Test coverage of these methods is low. We should beef it up.
The text was updated successfully, but these errors were encountered: