Repository files navigation

Tutorial & full documentation

Query playground -- try out the SQL dialect live!

Rezoom.SQL is an F# ORM for SQL databases.

It integrates with the F# compiler via a generative type provider to staticallytypecheck its own dialect of SQL. It knows how to translate this SQL dialect tovarious backends. Currently it supports SQLite, SQL Server, and PostgreSQL.

The type provider makes it fast and easy to write SQL statements, run them, andconsume their results from your F# code with full type safety. You don't need toinstall any editor extensions or custom tooling, just add a NuGet package andyou're off and running writing code like this:

In order to typecheck your queries, Rezoom.SQL has to know your database schema(so it can know, for example, that theId column in theUsers table is anint). It learns the schema by reading your migration scripts and observing whattables and views are created, columns added, and so on.

When developing the first iteration of your application (or a new feature withits own migration script), it's easy to sketch out a model then go back andchange it as you code, without having to touch a real database until you'reready to run.

Here's an example. You might want to refresh the page to start the GIF from thebeginning.

Because this is a generative type provider, it makes plain old .NET types youcan use from other languages. That is, you can write an F# project that usesRezoom.SQL and defines your migrations and queries, then reference that from C#or VB.NET projects and use the generated query types with no problem in thoselangages. There is even an option to represent nullable types with C#-styleSystem.Nullable<T> instead ofFSharpOption<T> to make this scenario workextra smoothly.

Check out thequeryplayground to seewhat kinds of SQL you can write.

When you make schema changes -- for example, replacingFirstName andLastName fields with a singleFullName field -- it's comforting to know thecompiler will point out the queries you need to update.

The typechecker also tightens up the feedback loop, so you don't waste your timetracking down typos and trivial SQL mistakes you'd normally only encounter at runtime.

Here are just a handful of possible errors you'll be informed of at compile timeand can fix in seconds. There are currently over 45 different error types thatcan be detected at compile time.

Since Rezoom.SQL understands the language, it knows that some migrations likealter table X add column Y andalter table X add column Z can be run in anyorder and produce the same effects.

When you're working with a team, you can take advantage of this to add thetables and columns you need for the feature you're coding, while your other teammembers do the same for their features --without having to decide theOneTrue Migration Order when you merge.

See detailshere.

You can use Rezoom.SQL by itself, as in the example code above.

But as the name implies, it's designed to work withRezoom. When you use it with Rezoom, you cantake advantage of automatic caching and combine units of business logic to share round tripsto the database.

With Rezoom, you build up aPlan to represent a transaction, which may involvemultiple SQL commands (or web API calls, or other high-latency data manipulation).

If you have onePlan calledthreeTrip that makes 3 queries, and anothercalledtwoTrip that makes 2 queries, you can choose whether to combine themsequentially for 5 round trips to the database...

letsequential=    plan{let!x= threeTriplet!y= twoTripreturn(x, y)}

Or concurrently, for 3 round trips to the database. The first two query batchessent to the database will include pending queries fromboththreePlan andtwoTrip:

letconcurrent=    plan{let!x,y= threeTrip, twoTripreturn(x, y)}

Each statically typed query comes with some useful info for caching:

• A compiler-generated ID
• A boolean indicating whether it could make sense to cache (has no side effects, does not use rand(), newid(), etc)
• A bitmask of the tables it reads from
• A bitmask of the tables it writes to

Rezoom uses this cache info to avoid unnecessarily re-querying for the same dataduring the execution of aPlan (i.e. within a transaction).

This means if you have 30 different functions that callLoadUserPermissions(currentUserId), only 1 query for permissions will actuallybe run when you use those functions together in a transaction. Unless, ofcourse, you edit the permissions table during the course of the transaction, inwhich case the cached result will automatically be invalidated and thepermissions re-queried next time they are requested.

This lets you safely check all the invariants you need for each method in yourdomain layer, without fear of causing mountains of redundant queries, andwithout any of the effort of writing your own caching layer.

To get started using RZSQL, read thetutorial. It'll get youup and running in 5 minutes or your money back.