InterpolatedSql supports db string format hints on non-string parameters, fixes #8

[terryaney]

Updated TransformArgument to support non-string types when adding dbType format hints.

• Changed regex processing to a single regexDbType expression to reduce code duplication that already existed and would increase if I followed the pattern in supporting non-string types (at least as far as I could read and follow code pattern)
• Fixed what I believe was a bug in the IsAnsi assignment for text vs ntext. I believe they were reversed. Let me know if I'm wrong.
• Hopefully the new 'flow/pattern' of code with a more generic regular expression combined with some string[].Contains() made code easier to read, if not, I can put back the pattern you originally had and try to add support for this feature.

Updated SqlTests

• Added TestFormatTypes. Familiar with xUnit vs nUnit and wanted something like [Theory] and [InlineData] but didn't know how to quite pull it off, so just made my own array of 'test data' to reduce the duplication of the same assert logic over and over for testing all the dbtype formats.
• Ensured all tests were passing in my 'first commit' before modifying parser in second commit and verifying all tests were still passing.
• Added a test case for {XElement:ntext} to verify new feature worked.

[Drizin]

Looks good, thanks a lot!!

I've made some minor changes (mostly to keep net462 compatibility) - please let me know if anything looks wrong.

Good catch on the IsAnsi bug, thanks!

[terryaney]

Only comment I have is, your original code (if I'm reading right), when argumentValue was null, it would end up hitting the code below (note, I didn't really understand what this else if was doing, I just 'ignored it' since I didn't feel I was changing behavior around it):

                else if (dbType == null && Enum.TryParse(value: testedFormat, ignoreCase: true, result: out parsedDbType))
                {
                    argumentValue = new DbTypeParameterInfo(null, argumentValue, direction, parsedDbType);
                }
                else
                {
                    matched = false;
                }

I tried to preserve that, but now if null it will process the argument if format is correct and turn argumentValue into a StringParameterInfo. I know you protect from null exception with your method using the null coallece...

        protected virtual string? TransformStringArgument(object? argValue)
        {
            return argValue is string v ? v : argValue?.ToString();
        }

So, behavior was changed. You know better than me if that is right or not.

[terryaney]

Hey @Drizin ,

Did you have any response to my concern above?

Additionally, there might be a problem with nuget. Your repo shows 2.1.2 for InterpolatedSql.Dapper:

But nuget seems to only know about 2.1.0?

Thanks, Terry

[Drizin]

The readme had a typo (wrong package). I have only republished the base library (InterpolatedSql), but not InterpolatedSql.Dapper. I wasn't sure if I should bump both when only one had a fix, so I didn't. So I guess you can just add a reference to InterpolatedSql and upgrade it individually.

[Drizin]

Regarding the change of behavior, I guess it was a bug - if the type is explicitly described (like varchar(200)) then I think it doesn't matter if the provided argument is null (does it make sense?). Probably I should improve the test coverage for that, but I guess it was just a bug. Thanks for following up, though.

[terryaney]

OK. When do you plan on updating nuget? Probably is pattern to easily switch from local build (if I pulled and built) to nuget ref that I don't quite have mastered ;)

[terryaney]

@Drizin Actually, before I just referenced InterpolatedSql.Dapper which pulls in InterpolatedSql automatically. Should I just add an additional reference to the (updated) InterpolatedSql package?

[Drizin]

Yep.