-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Enable BeginExecuteReader methods #33660
Enable BeginExecuteReader methods #33660
Conversation
Looks pretty simple. You'll want to CC in a few people to get their attention since this is their area, @afsanehr, @keeratsingh, @David-Engel. |
IAsyncResult result = command.BeginExecuteReader(); | ||
while (!result.IsCompleted) | ||
{ | ||
System.Threading.Thread.Sleep(100); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is supposed to throw InvalidOperationException
when The name/value pair "Asynchronous Processing=true" was not included within the connection string defining the connection for this SqlCommand.
Doc Link
Can you check for that condition? If the connection string that is passed in doesn't have Asynchronous Processing set to true, then the test should add the parameter to the connection string.
Instead of testing BeginExecuteReader with a Sleep statement, could you test an overload which takes in a callback, which is called when the execution finishes? This way you can test EndExecuteReader in the same function and it could provide more branch coverage.
Alternatively, could you add a test which tests the callback paths?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was confused with "Asynchronous Processing" too. I have added test with callback.
@dotnet test Windows x64 Debug Build |
@@ -425,6 +425,11 @@ public sealed partial class SqlCommand : System.Data.Common.DbCommand, System.IC | |||
public System.IAsyncResult BeginExecuteXmlReader() { throw null; } | |||
public System.IAsyncResult BeginExecuteXmlReader(System.AsyncCallback callback, object stateObject) { throw null; } | |||
public System.Xml.XmlReader EndExecuteXmlReader(System.IAsyncResult asyncResult) { throw null; } | |||
public System.IAsyncResult BeginExecuteReader() { throw null; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@galakt These edits should be added to System.Data.SqlClient.NetCoreApp.cs and not the System.Data.SqlClient.cs file.
These new APIs should be exposed in netcoreapp specific build. Netstandard cannot be updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really confused by this:
- This is exposing APIs which are available on .NET Framework (see https://apisof.net/catalog/System.Data.SqlClient.SqlCommand)
- How i can break Netstandard while AFAIK Netstandard have no SqlClient mentions (https://github.com/dotnet/standard/tree/master/netstandard/ref)
- What difference of this PR and Enable BeginExecuteNonQuery functions in .NET Core #26016
Btw, i have moved ref changes to the NetCoreApp.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @galakt
@danmosemsft My understanding is that any new APIs added even to existing types, should be moved to netcoreapp specific builds based on the conversations we had on this thread. #32245 (review)
Is this assumption correct? I guess we will need to update the baseline files to represent this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@danmosemsft Can we finally resolve question about place for my Refs please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we have been consistent - @ericstj?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@karelz Sorry, can you push this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@saurabh500 @ericstj @danmosemsft Any updates on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SqlClient is not part of netstandard, so its APIs are not pinned by being in netstandard. You do however, need to consider support. If you add API to the reference assembly you should be sure it is supported everywhere that API can be used. So if you're exposing it in a netstandard2.0 reference assembly this means it needs to be supported in .NET 4.6.1 and later, .NETCoreApp 2.0 or later, UAP, etc (see https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support). For UAP and NETCoreApp you can simply update the implementation assembly that is in the package, desktop is the limiting concern here since you cannot update that (and perhaps mono/Xamarin).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@saurabh500 If i understood correct, i should revert "move to NetCoreApp.cs" commit. Am i right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move the ref changes to the netcoreapp.cs file.
@dotnet test NETFX x86 Release Build |
looks like you might need to add platform specific exceptions for the test(s). |
@Wraith2 See no sense in any new changes, we still on stage of deciding where Refs must be (look at last review conversation) |
This reverts commit 860ef7c.
…__ExecuteReader_methods
Reverted references move |
Ready to merge after @afsanehr confirms a test pass. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests passing.
…der_methods Enable BeginExecuteReader methods Commit migrated from dotnet/corefx@fea701f
According to #17126.
Methods have been made public,
overloads have been added,
single manual test on success has been added.
This is my first PR to corefx.