Hi everyone, what is like the go to way to interact with SQL databases in F#?
I have seen the recommandations on: Guide - Data Access | The F# Software Foundation. Looks like there are multiple ways but not really a goto way. And a lot of the project seems not really maintained. Or look like hobby projects.
I also know that i could use the entity framework. But for me that code just ends up to be like c#. and at that point i could as well write everythin in c#.
But I would love if there was a nice way to handle SQL databases in F#. I love the giraffe framework and it would be amazing if there was a library that is well supported that could handle database interactions.
In my opinion, the SQL language (despite several flaws) is the best way to query an SQL database. SSDT projects in VS are also very good, allowing you to define databases in source control with some (incomplete but still useful) degree of type-safety.
ADO.Net is the fastest way to access queries defined in SQL (stored procedures, UDFs, etc.).
For a typed link between the two you can use GitHub - cmeeren/Facil: Facil generates F# data access source code from SQL queries and stored procedures. Optimized for developer happiness. . The approach is:
- deploy the database to localdb when generating code
- use Facil to generate ADO.Net code to access tables, stored procedures, UDFs.
- do something to guarantee that the ADO.Net code matches the sql files. You can have a test to generate them and check that the code is the same, but to save time we just put a hash of sql files in the generated code with a test to ensure that we don’t accidentally change the sql files without generating the code.
I don’t use Facil but it looks very robust. We use a small library to do the same (just 500LOC and I could make a gist of it if interested).
We’re fairly happy with using SqlHydra for our use case where there’s a pre-existing database and we want to generate F# code to query it. It’s well-maintained, though it does feel like a lot hinges on the project owner. There’s a lot less “magic” to SqlHydra than EntityFramework, since it pretty much just generates type-checked sql queries for you; it’s not an ORM.