Rezoom.SQL: Statically typed SQL for F#

Relevant for folks:

FSharp.Data: http://fsharp.github.io/FSharp.Data/

SqlProvider: http://fsprojects.github.io/SQLProvider/

FSharp.Data.SqlClient: http://fsprojects.github.io/FSharp.Data.SqlClient/

Azure Storage Type Provider: https://github.com/fsprojects/AzureStorageTypeProvider

For rapid prototyping, I think ORMs are still the best solution. However, their benefits start to diminish when scaling the team and product start becoming priorities. Working /with/ the database becomes a lot more fruitful than trying to wrangle it to your format. After all, web applications are just database skins.

The choice to typecheck a SQL dialect directly instead of using an embedded DSL like LINQ is uncommon enough that it gets the majority of the focus in my own documentation. However, it wasn't what motivated me to create the project.

I wanted to have an ORM that could take full advantage of my resumption monad library, Rezoom. This library is similar in concept to Facebook's Haxl or Dataloader, in that it can combine independent requests into batches and cache ones that have already been resolved.

The main difference (besides being F#) is that it is intended to be used for mutations, not just queries. This is a bit tricky because when you mutate the stuff in the database, that may invalidate the cached results of previous queries. The problem isn't too bad since, as with Haxl and Dataloader, the cache is per-request so it's very short lived, but it could still cause problems. Contrived example:

  // domain layer line item logic, includes business rules
  // returns the updated invoice
  let addLineItem invoiceId lineItem =
    plan {
      // query for the invoice
      let! invoice = DB.getInvoiceById invoiceId
      if invoice.IsSent then
        failwith "Can't edit this invoice because it has been sent"
      // run INSERT/UPDATE statement(s)
      do! DB.addInvoiceLineItem invoiceId lineItem
      // re-query for the invoice to get its current state
      return! DB.getInvoiceById invoiceId
    }

The way Rezoom solves this is to have "errands" (its word for a batchable data dependency) specify 2 128-bit masks. One represents its dependencies, the other represents its invalidations. When you run a command with a non-zero invalidation mask, all the cached results whose dependency bits overlap with the invalidation bits get evicted.

The caches are local to a "category" which is pretty much just a tag for which library created the errand, so that the errands wrapping, say, a web API don't stomp on the caches for the errands talking to a SQL database (actually the connection string is involved too so you can deal with multiple databases from one app). For the errands generated by Rezoom.SQL, each bit in the mask represents one table, so running an UPDATE/INSERT/DELETE invalidates the cache for all commands that read from the affected tables. If you have more than 128 tables in your database the IDs wrap around so you'll get some false invalidations possibly hurting performance, but never a false cached result hurting correctness.

This all could make it very easy to write a GraphQL server backed by Rezoom + Rezoom.SQL.

I think type providers are a really fantastic feature. I just wish that I had more cause to write f#.

I am currently with SqlProvider but raw SQL would be interesting option =)