-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generated types for performance #404
Comments
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. |
@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 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. |
We should consider making a generated type provider. There are previous closed threads (#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. #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 #329 .
This workflow would operate similarly to SQL+ .NET, i.e. providing a way to get dotnet code from an sql project.
The text was updated successfully, but these errors were encountered: