Uh oh!
There was an error while loading. Please reload this page.
Only check inexact match when no exact match is found. - #668
Conversation
cheenamalhotra
commented
Jul 27, 2020
Is there a test case to verify the fix? |
yyjdelete
commented
Jul 28, 2020
Infact, I don't know how to create an test for this internal api. And maybe it's not a problem due to it's internal and there is no dupe tables with different case actually used by public apis. |
roji
commented
Jul 28, 2020
@yyjdelete it may be worth looking into this a little further and finding an actual user impact - since the current implementation does seem buggy. |
Wraith2
commented
Jul 28, 2020
If it isn't testable but is clearly a fix I'm fine with merging it but testing does always need to be considered een though writing tests sucks. |
David-Engel
commented
Jul 28, 2020
This bug would only surface if the embedded resource, Microsoft.Data.SqlClient.SqlMetaData.xml, contained multiple MetaDataCollections with a CollectionName differing only by case and the desired entry (case sensitive match) appeared before the undesired entry (case insensitive match). Testing the bug would be awkward. I'm fine with simply fixing the bug. Bonus points if a couple lines are added to TestGetSchema to test |
yyjdelete
commented
Jul 29, 2020
@David-Engel |
Fixdotnet/runtime#39620
The same as dotnet/runtime#39961
Avoid the exact match result be overwrite by later inexact ones.
This may not happen due to limited callsites, just make the code more clear.