Add a setting to turn off Ole Db "smell check"

[Giorgi]

Implements #1971

[mgravell]

a few comments inline; needs some kind of test; this is a little awkward because of concurrency concerns, but we should at least try

[Giorgi]

I think it now should work correctly in both cases but I'm not sure how to test it.

[mgravell]

Re testing; IIRC in the original ticket there was an example where it did the wrong thing; can we not just use something based on that to show it continuing to fail when set to true and working when set to false? The only caveat is that we should use try/finally to set the value back to what it was originally after the test

[Giorgi]

I tried #1914 and it still throws the same exception.

[mgravell]

I tried #1914 and it still throws the same exception.

well yes, but that is a different glitch; I wouldn't expect that to change, so it is good that it didn't - however, we should be able to validate with a scenario more like #1971 - for example:

        [Theory]
        [InlineData(true)]
        [InlineData(false)]
        public void OleDbParamFilterFails(bool yourNewSettingHere)
        {
            var oldValue = SqlMapper.Settings.YourNewSettingHere;
            try
            {
                SqlMapper.Settings.YourNewSettingHere = yourNewSettingHere;

                if (yourNewSettingHere) // OLE DB parameter support enabled; can false-positive
                {
                    Assert.Throws<NotImplementedException>(() => GetValue(connection));
                }
                else // OLE DB parameter support disabled; more reliable
                {
                    Assert.Equal("this ? could be awkward", GetValue(connection));
                }
            }
            finally
            {
                SqlMapper.Settings.YourNewSettingHere = oldValue;
            }

            static string GetValue(DbConnection connection)
                => connection.QuerySingle<string>("select 'this ? could be awkward'",
                    new TypeWithDodgyProperties());
        }
        class TypeWithDodgyProperties
        {
            public string Name => throw new NotSupportedException();
        }

I haven't executed that at all, note

[mgravell]

looks good; can you add a release-note entry? for an example see index.md here: a37b151#diff-b4d68dc855d0f9476d3f2ee343853bd21bf82ea9960d0cf06661baa244439dd6

[mgravell]

also, can you confirm you're free and willing to contribute this code irrevocably etc in line with the project license, i.e. "don't sue me later"

[mgravell]

Note: re the pseudo-positional parameter support (#1914) - that's one that Dapper.Analyzer will definitely be helping with ASAP; the problem is that we don't want to have to constantly parse SQL, so for @foo and ?foo?, at runtime we kinda have to do things the "probably" way; however, Dapper.Analyzer can take the time at build to do a full parse, find the actual parameters, and offer a warning and advice on workarounds. So if that one is hurting you: worry not!

[Giorgi]

looks good; can you add a release-note entry? for an example see index.md here: a37b151#diff-b4d68dc855d0f9476d3f2ee343853bd21bf82ea9960d0cf06661baa244439dd6

Under the ### unreleased section?

[Giorgi]

also, can you confirm you're free and willing to contribute this code irrevocably etc in line with the project license, i.e. "don't sue me later"

I confirm

[mgravell]

Merged with thanks