Remove "Experimental" in name

[fsprojects]

Remove "Experimental" in name

[dmitry-a-morozov]

Agree but I have bigger plans in mind :).
Currently SqlCommandProvider supports 2 kinds of sql :

• classic T-SQL scripts (default mode)
• Stored Procedures by name. This archived by directly specifying sp name and setting CommandType.StoredProcedures

type UpdateEmplInfoCommandSp = SqlCommand<"HumanResources.uspUpdateEmployeePersonalInfo", connectionString, CommandType.StoredProcedure >

I'm personally not big fan of stored procedures. They remind me so much of imperative style but people use it so make sense to support.

A lot of code in the type provider dedicate to handle second case. Also, there are requests to support SP specific features like out params and return values etc. All this doesn't fit very well into model of pure T-SQL queries.
So here is an idea: create type provider called SqlProgrammability which will reflect subset of Programmability leaf in SQL Server Managment Studio:

We'll target user defined types (including User defined table types), stored procedures and functions.

Usage will be like following:

[<Literal>] 
let connectionString = @"Data Source=(LocalDb)\v11.0;Initial Catalog=AdventureWorks2012;Integrated Security=True"

type AdventureWorks2012 = SqlProgrammability<connectionString>

let db = AdventureWorks2012.GetDataContext()
db.StoredProcedures.``HumanResources.uspUpdateEmployeeHireInfo``.AsyncExecute(...)
db.Functions.``dbo.ufnGetContactInformation``.Sample(top = 100, ...)

• this provider can be used to do programmability exploration of sql server
• SqlCommandPrivder will be relieved from SPs specific support which will make usage simpler and intuitive
• types definitions can be shared for SqlProgrammability which is not possible or needed for SqlCommandProvider.

If you like this idea, once we done with development which should be too long (~1 month) we can combine 2 providers into single lib and call it something like FSharp.Data.SqlClient.

[jackfoxy]

All the literature says to use type providers because of statically compiled plans, etc. (or something like that, I haven't kept up), but in practice fully parameterized inline T-SQL is just about as efficient. (It's about impossible to do definitive benchmarks.)

To me the transparency advantage of inline T-SQL which gets correctness checked as you edit it along with the rest of your F# is just huge.

I'm not sure breaking out into 2 TPs has many advantages. It fragments the SQL TP space. I like more features supporting programmability, but why should SQL Server have 2 TPs when there is another TP that supports all the other relational databases (and LinqToSql, if that is your preference).

BTW, I think SqlCommandProvider (when docs are reasonably complete) is already good enough for full incorporation into FSharp.Data. Maybe with the additional programmability it should be renamed to SqlServerProvider,to distinguish that this is for power use on SQL Server and SqlProvider will be for all other RDBMSs or if you really prefer LinqToSql on SQL Server.

Looking forward to talking to you about this and lots of other good stuff next week!

[vasily-kirichenko]

I'm with @dmitry-a-morozov here. What's more, I don't see the current SqlCommand TP to be very useful, this is because I don't use ad-hoc queries at all.

I think, there's two distinct styles of development, the first is where most of the business logic is in application code, the second - where it is in the DB. So, it'd be very natural to have two distinct type providers - SqlCommand for ad-hoc- and SqlProgrammability - for "BL in the DB" architectures.