This seems cool... How about MySQL support?

[Thorium]

This seems cool. Many times users start with SQLProvider because it's fast to start with, and works fine with any size of database. But then at some point users may have a need to write a manually for what-ever reason. Linq is not perfect. For now, the solution has been to write a stored procedure, which is unoptimal as other program logic is in F#-code. So I can see these two could work well side-by-side on a project.

The main drawback of FSharp.Data.SqlClient has been lack of other databases.
But they have a good comparison page, this could be added there, just send a PR and try to be objective: http://fsprojects.github.io/FSharp.Data.SqlClient/comparison.html

Are you planning to support Mysql and Oracle?

[rspeele]

Hi. I'm happy to hear that you like the project. SQLProvider is definitely the canonical ORM for F# users.

Adding support for other database backends should be pretty simple, but is not at the top of my priorities for the time being. MySQL would definitely come first, Oracle much later. I'd like to have a plugin system where you could point to an assembly in rzsql.json, and type provider would load additional IBackend implementations from there.

In case somebody reading this wants to try their hand at adding a backend, these are the current steps:

• Define a list of supported functions and their types. This doesn't have to be exhaustive to start with. Actually I'd save this part for last since it's pretty mind-numbing.

• Define a migration backend. DefaultMigrationBackend handles most of it, but it doesn't know how to create the database if one does not exist.

• Define a LiteralTranslator, ExprTranslator, and StatementTranslator (like these). Here you can inherit from the default implementations, and just override the parts where your backend's syntax differs from RZSQL. Check the others for examples: TSQL is really complicated, SQLite is almost nothing since RZSQL has virtually the same syntax, Postgres is somewhere in between.

• Implement IBackend using all that stuff, like here

• Give your backend a name and add it to the config parser for rzsql.json

• Write tests for the special SQL translations done by your backend. Most important is to have a "smoke test" that checks the translated SQL for a reasonably complex set of schema operations and a query, like this. You run the translated SQL by hand on a real database to make sure it works, then paste it into the "expectation" for the test so future changes to the output can be re-checked.

[rspeele]

Closing since #5 and #6 cover it now.