Consider showing how this can be used with SQLProvider
See issue here: https://github.com/fsprojects/SQLProvider/issues/86
"The FSharpComposableQuery nuget package is an interesting approach to normalizing F# queries to allow them to be more compositional and safe. It would be interesting and useful to check if this approach to queries can be used in conjunction with SQLProvider and assess whether it brings benefits...."
@pezipink and @colinbull are two contributors to SQLProvider.
I've confirmed that it can be used with SQLProvider on (very) simple examples, using SQL Server, as follows:
-
Replace the SqlDataConnection line with SQLDataProvider (same connection string)
-
Change the nice table references (e.g. [db.Table]) generated by SqlDataConnection to the yucky ones [db.
[dbo].[Table]] generated by SqlDataProvider
It will take a little while to redo all of the testcases we had written for the standard type provider, but (as long as SqlProvider is broadly compatible with the expressions supported by the standard type provider) I don't see any reason to believe that anything major breaks.
--James
The Sql provider defines a couple of bespoke for handling nullables, optionals and membership, for example |=| which represents IN. On quick look through the docs, it looks as if this sort of thing is supported, so that shouldn't be a problem.
As for the table names, I'm planning on putting together a pull request that sorts this out so they are nicer and look more like normal properties. Or maybe even make them match what the SQLDataProvider returns, just so things are consistent. If this change is made would you still the changes you speak about to your test suite?
Cheers Colin
Hi,
Sorry, I realize that may have sounded unnecessarily critical. Changing the name treatment would save me a little work, but isn't urgent - I think it's just a matter of search and replace. Though, longer term having the same behavior as SqlDataProvider would probably be helpful for making it easier for people to try out SqlProvider.
As discussed in fsprojects/SqlProvider#86, FSharpComposableQuery just transforms and simplifies the quoted query expression and doesn't add any advanced features, just passes them through if they're there. So it should be relatively agnostic to whatever the underlying query provider does - it may make queries work that didn't before (by normalizing away features that it doesn't handle) but shouldn't break queries that normally work (if it does, let us know!)
--James