Generated types for performance

[charlesroddie]

We should consider making a generated type provider. There are previous closed threads (https://github.com/fsprojects/FSharp.Data.SqlClient/issues/61, ) that have focused on C# friendliness, which is a very good goal, but this is about performance at design-time.

The performance advantage of genreated types is that it can use the build system and therefore run at predictable times and manually. A very small project can use the FSharp.Data.SqlClient with a reference to a database connection, and then be built. Any referencing project will get usable intellisense performance without the performance issues that plague this library. https://github.com/fsprojects/FSharp.Data.SqlClient/issues/343 . It would also address cases where the type provider does not know when to update types, since there is no way to control this manually at present https://github.com/fsprojects/FSharp.Data.SqlClient/issues/329 .

This workflow would operate similarly to SQL+ .NET, i.e. providing a way to get dotnet code from an sql project.

[charlesroddie]

A workaround which generates types usable from other projects in a standard way, is to create functions or types out of the provided types in a separate project.

E.g. files containing:

let myUserDefinedFunction(conn:SqlConnection) (arguments...) = async {
    use cmd = new db.MyUserDefinedFunction(conn)
    return! cmd.AsyncExecute(arguments...)
    }

Split over a number of files to maintain IDE performance.

Then a referencing project will become snappy to work with. This makes IDE performance manageable, at the cost of additional code. It doesn't improve runtime performance which is negligibly affected.

[smoothdeveloper]

@charlesroddie thanks a lot for explaining how you work around IDE performance issue.

The main issue for switching for generated types is that there needs to be a way to generate the IL, I'm not familiar but it would be significant work.

In my use case, I have files with a bunch of SqlCommandProvider pointing for each .sql file, all in a single F# file, and similar as you say, helper functions broken down in domain specific files.

There seems to be some incompressible amount of work when the IDE initialize a project that uses the provider and I think it is more related to the TP SDK and how it binds to the tooling rather than this specific provider.

After the tooling initialized the project, the tooling performance is acceptable, I have a hundred or so of .sql files and didn't seem it wouldn't scale linearly.