Programmability TP API suggestions

[fsprojects]

Programmability TP API suggestions

[dsevastianov]

SPs are loaded lazily, so it won't help performance. As for the Stored Procedures, we are trying to mimic SSMS experience for the user, but maybe you're right, it's not necessarily very useful.

[dmitry-a-morozov]

@vasily-kirichenko I think we'll keep Stored Procedures for now mostly because there is value in using widely accepted terms. You alleviate the issue by using local alias:

let procedures = myDb.``Stored Procedures``.
procedures.``dbo.MyProc``.AsyncExecute()

We'll work on performance/responsiveness improvements.

Question: would you mind if we'll remove SP support from SqlCommandProvider? I mean we'll remove CommandType parameter. So stored procedures can be called only via EXEC.

Also, what do you think about packaging? Should both type providers be in one project/nuget package? Or separate ones?

[vasily-kirichenko]

I agree with removing CommandType parameter from SqlCommand TP.

What about packaging, I think it's ok to put both the TPs into a single package, since it's quite common to use some ad-hoc queries along with SPs (at least in my daily job).

Parameters/result type inference in SqlProgrammability is awesome (so far). However, it's uncovered another problem - it's very easy to get lost in big tuples, where we don't have result column names, like this:

sp.AsyncExecute(@LastDayCount: int, @MD5: byte []) : Async<Collections.Generic.IEnumerable<string * DateTime * bool * Option<string> * Option<string> * string * Option<DateTime> * Option<string> * Option<int> * int * Option<byte> * byte>>

As a result, I have to go to the Sql Server Management Studio to consult what all this mean. Is it possible to return records instead?

[dmitry-a-morozov]

@vasily-kirichenko You can use ResultType.Records instead of default ResultType.Tuples.

[dsevastianov]

How about switching default to Records?

[vasily-kirichenko]

With ResultType=ResultType.Records the TP is fantastic! :) It inferences literally everything. Cool.

I agree with switching to Records as default result type, great idea.

[vasily-kirichenko]

However, I think it's better to generate string option for all string parameters (varchar, nvarchar, text...) instead of string. Here we have inconsistence between strings and all other types, i.e.:

DB int <=> int option
DB tinyint <=> byte option

but

DB nvarchar <=> string

[dsevastianov]

I'm not sure about that. string is reference type, not struct. I think this behavior is well-aligned with what is commonly expected.

[dsevastianov]

Default result type for SqlProgrammability switched to Records