-
Notifications
You must be signed in to change notification settings - Fork 291
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
Change DbDataReader.{GetSchemaTable,GetColumnSchema} to return empty results when there is no resultset #417
Comments
Thanks @roji We will investigate and address soon! |
For compatibility we could put in an AppContext switch allowing people to revert to the previous behaviour if they need to, it isn't a high performance method so the overhead would be irrelevant. If I want I can make these changes @cheenamalhotra |
Remove unused code from DataReaderTest fixes dotnet#417
@Wraith2 Sorry, already on it. I assume 2.0 means "ok with breaking changes" ? |
No problem, all yours 😁 |
I will await comments from the product team |
We're accepting breaking changes for this release if the changes have been long awaited and there is no workaround, or make us in-alignment with Specs. Basically we're open for improvements that make most sense! :) |
Would you like to have an AppContext switch to enable the previous behaviour @cheenamalhotra or @roji |
I'm not super knowledgeable about our practices, but AFAIK we tend to do that more for risky patches, rather than for intentional behavior changes such as this. Maybe @ajcvickers has an opinion? |
I agree with @roji If there's no special request for AppContext, we're ready to take in changes. |
@cheenamalhotra I don't think the AppContext switch would be right here. We expect the impact of this change to be very minimal, and if people do hit it then they should be able to easily change their code to work again. This is better than having customers set a switch if they hit this break because we would then have to support the switch and both behaviors going forward. So, yeah, agreeing that we should just make the change. |
I have looked in GitHub codebase, and seen many usages of GetSchemaTable where the user never expects it to return null. |
As above I think the solution to that would be to change the default as agreed since it's a desired breaking change and then add an appcontext switch for people that want to put it back. They'll need to investigate and read the release notes to find the switch and in doing so will now understand that they may be doing something wrong. At that point if they're the author they can change their code and if they're a consumer then can either push back on the author or if absolutely required set the context switch in their own app. |
@Wraith2 I do not understand? Just now, nobody expects the return value to be null - so nothing will break for them. |
Oh, negation. Ignore me, carry on. |
As discussed in dotnet/runtime#509 and recently offline. This would be a small breaking change (so ideally done in the upcoming 2.0.0), which would make these methods more consistent and more usable in the new null-annotated world.
/cc @David-Engel @cheenamalhotra @ajcvickers @bricelam
The text was updated successfully, but these errors were encountered: