This repo contains the material I used for a HaskellerZ meetup in Zurich.
You can can see information about that here.
You can also see the slides in PDF here.
Make sure you have PostgreSQL installed and run the files in the sql directory.
Libraries like Opaleye and Haskell Relational Record make use of Haskell's type system to provide an abstract way of composing SQL queries that are guaranteed to be valid.
In the material I'm using PostgreSQL.
A basic way of talking to a PostgreSQL database is using
postgresql-simple.
While really useful, this library makes us write repetitive queries.
Furthermore, it's string-based, so when running our queries against the
database to get results in some Haskell data type, we're not guaranteed upon
compliation time that the software is sound from a type perspective.
This is not the "Haskell way" of writing programs.
Composability means taking small, well-tested queries, and "mixing" them in some form. From there we can restrict them, join them, aggregate, count, order, and deliver a composable structure that can be reutilized. When we start composing queries, we also touch on the subject of projecting them. Projection means discarding columns from our queries.
Through projection and other means of composition we can achieve arbitrarily complex results while keeping a comprehensible and modular approach. Both Opaleye and Haskell Relational Record ensure meaningful composition with the use of different techniques.
In Haskell, we normally see declarations such as
data Foo a = Foo { _a :: a }. What's on the left side of the = is the
type, and on the right are the terms. Type information is useful at compile
time, Haskell makes great use of type information to make sure that our
programs are safe.
If we can somehow abstract our queries and give them type information, then we could use them throughout our program to make sure that our queries "make sense" from a type perspective. This means that when we compare fields, that those fields are of the same type; when we're joining, our joins are upon compatible fields, etc. Furthermore we want to make sure that when we run queries against our database, that those results have a meaningful representation as Haskell values.
Both Opaleye and Haskell Relational Record exploit the type system via different means to make sure, on compile time, that our queries "make sense".
Carlos D'Agostino carlos.dagostino@gmail.com