Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
/ corefx Public archive

Enable BeginExecuteReader methods #33660

Merged
merged 9 commits into from
Dec 20, 2018

Conversation

galakt
Copy link

@galakt galakt commented Nov 22, 2018

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.

@dnfclas
Copy link

dnfclas commented Nov 22, 2018

CLA assistant check
All CLA requirements met.

@Wraith2
Copy link
Contributor

Wraith2 commented Nov 22, 2018

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);
Copy link
Contributor

@saurabh500 saurabh500 Nov 26, 2018

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I read more documentation

https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlconnection.connectionstring?view=netframework-4.7.2

image

Please ignore the struck out comment above.

Copy link
Author

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.

@keeratsingh
Copy link

@dotnet test Windows x64 Debug Build

saurabh500
saurabh500 approved these changes Nov 28, 2018
@@ -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; }
Copy link
Contributor

@saurabh500 saurabh500 Nov 28, 2018

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.

Copy link
Author

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:

Btw, i have moved ref changes to the NetCoreApp.cs

Copy link
Contributor

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.

Copy link
Author

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?

Copy link
Member

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?

Copy link
Author

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?

Copy link
Author

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?

Copy link
Member

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).

Copy link
Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@galakt Yes that is right.
@ericstj Thanks for the clarification.

Copy link
Contributor

@saurabh500 saurabh500 left a 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.

@galakt
Copy link
Author

galakt commented Dec 1, 2018

@dotnet test NETFX x86 Release Build

@Wraith2
Copy link
Contributor

Wraith2 commented Dec 5, 2018

SQL\AsyncTest\BeginExecReaderAsyncTest.cs(43,47): error CS1061: 'SqlCommand' does not contain a definition for 'BeginExecuteReader'

looks like you might need to add platform specific exceptions for the test(s).

@galakt
Copy link
Author

galakt commented Dec 5, 2018

SQL\AsyncTest\BeginExecReaderAsyncTest.cs(43,47): error CS1061: 'SqlCommand' does not contain a definition for 'BeginExecuteReader'

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)

@galakt
Copy link
Author

galakt commented Dec 20, 2018

Reverted references move
Synced with changes from #34112

@saurabh500
Copy link
Contributor

Ready to merge after @afsanehr confirms a test pass.

Copy link
Contributor

@AfsanehR-zz AfsanehR-zz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests passing.

@AfsanehR-zz AfsanehR-zz merged commit fea701f into dotnet:master Dec 20, 2018
@galakt galakt deleted the Enable__ExecuteReader_methods branch December 21, 2018 09:16
@karelz karelz added this to the 3.0 milestone Dec 21, 2018
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
…der_methods

Enable BeginExecuteReader methods

Commit migrated from dotnet/corefx@fea701f
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants