Skip to content
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

Closed
anpete opened this issue Nov 23, 2016 · 1 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
Milestone

Comments

@anpete
Copy link
Contributor

anpete commented Nov 23, 2016

  1. When passing a strongly typed array for the parameters arg: E.g.
context.Database.ExecuteSqlCommand(
    "SELECT * FROM Orders WHERE OrderID = {0} OR CustomerID = {1}", 
    new [] { 1, 2 }));

We crash because the parameters object[] ends up with a single int[] element.

  1. The Async overloads require passing a cancellation token when specifying parameters.

Test coverage of these methods is low. We should beef it up.

@rowanmiller
Copy link
Contributor

We should look at adopting the pattern we use elsewhere for async methods (not combining params and CancellationToken). We should also look at an overload that takes an IEnumerable of parameters rather than params.

@rowanmiller rowanmiller added this to the 1.2.0 milestone Nov 28, 2016
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
@ajcvickers ajcvickers added breaking-change closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. labels Jan 26, 2017
@ajcvickers ajcvickers changed the title ExecuteSqlCommand/Async usability issues DbContext: ExecuteSqlCommand has poor usability when used with params and cancellation tokens May 9, 2017
@divega divega added closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. and removed closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. labels May 10, 2017
@ajcvickers ajcvickers modified the milestones: 2.0.0-preview1, 2.0.0 Oct 15, 2022
@ajcvickers ajcvickers removed their assignment Sep 1, 2024
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
Projects
None yet
Development

No branches or pull requests

4 participants