interpolated string support

[MichaelMcGlothlin]

I didn't see interpolated string support so I tossed it together for my own use. So I can then just do something like sqlConnection.Read<Person> ( $"SELECT * FROM people WHERE name = {name} AND birthdate = {birthdate}" ) and it should be properly handling the parameters.

`
public sealed class Query {
public static Query FromSqlInterpolated ( System.FormattableString formattableString ) {
var parameterIdentities = new string[ formattableString.ArgumentCount ];
var parameters = new (string, object)[ formattableString.ArgumentCount ];

for ( var i = 0; i < formattableString.ArgumentCount; i++ ) {
var parameterIdentity = "@p" + i;
var parameterValue = formattableString.GetArgument ( i );
parameterIdentities[ i ] = parameterIdentity;
parameters[ i ] = (parameterIdentity, parameterValue);
}

var command = System.String.Format ( formattableString.Format, parameterIdentities );

return new Query { Command = command, Parameters = parameters };
}

public string Command { get; init; }

public (string, object)[] Parameters { get; init; }
}
`

[vbilopav]

Thanks, I'll add this support asap.

[vbilopav]

After some investigation, It seems to me that there is no easy way to add elegant method overloads.

For example, if I have two overloads:

• Execute(string command)
• Execute(FormattableString command)

Both of these calls:

• connection.Execute("select 1, 2, 3")
• connection.Execute($"select {1}, {2}, {3}")

Would always call the first overload Execute(string command) since command parameter is compiled to string.

If I change entire interface to always use FormattableString instead of string, and basically kick out string overload entirely, then all calls would have to use $ for each command string, regardless if the use parameters or not, like this:

• connection.Execute($"select 1, 2, 3")

This might be most elegant solution, but I'm afraid that would break build for many existing users, so my current idea is to add new version of method for "Fmt" or "Format" suffix like this:

• ExecuteFmt(FormattableString command)
• ReadFmt(FormattableString command)
• ExecuteFmtAsync(FormattableString command)
• ReadFmtAsync(FormattableString command)

or

• ExecuteFormat(FormattableString command)
• ReadFormat(FormattableString command)
• ExecuteFormatAsync(FormattableString command)
• ReadFormatAsync(FormattableString command)

I don't know, should I break the build and introduce the elegant version or add this ExecuteFormat(FormattableString command) version.

What do you think?

[vbilopav]

Maybe it would be better to add these new methods

ExecuteFormat(FormattableString command)
ReadFormat(FormattableString command)
ExecuteFormatAsync(FormattableString command)
ReadFormatAsync(FormattableString command)

Because some people (including me), would like to still have the means to build SQL dynamically by using string interpolation and not treat string interpolation as SQL parameters.

The only question is are these new names descriptive enough?