From the first line of the code, my idea behind Dapper.FSharp was to create a simple and straightforward abstraction over SQL queries people tend to use most of the time. Initial idea was to create a single abstraction to cover the top three used SQL-based databases: MSSQL, MySQL, and PostgreSQL. Such a decision played well at the very beginning, but over time, and with a growing user base, there were many PRs to add more and more DB vendor-related features (e.g. #61, #65, or #70) which I had to reject for the sake of unified abstraction - I simply couldn't add features that would work only for one of the databases. And trust me on this - it never felt good to reject well-intended PRs.
So... I decided to start working on v4, which will be refactored from the ground. The main goals of this breaking change are:
Each DB vendor has a separate namespace with all the code (e.g. Dapper.FSharp.MSSQL)
Each DB vendor having own abstraction with its own computation expressions
Where possible, try to keep abstractions close together
Implement vendor-specific features on the CE syntax level
Dzoukr
commented
1 year ago
From the first line of the code, my idea behind
Dapper.FSharpwas to create a simple and straightforward abstraction over SQL queries people tend to use most of the time. Initial idea was to create a single abstraction to cover the top three used SQL-based databases: MSSQL, MySQL, and PostgreSQL. Such a decision played well at the very beginning, but over time, and with a growing user base, there were many PRs to add more and more DB vendor-related features (e.g. #61, #65, or #70) which I had to reject for the sake of unified abstraction - I simply couldn't add features that would work only for one of the databases. And trust me on this - it never felt good to reject well-intended PRs.So... I decided to start working on v4, which will be refactored from the ground. The main goals of this breaking change are:
Dapper.FSharp.MSSQL)Deconstructorand its functionalityETA: End of 2022, but no promises here...