opaleye VS esqueleto

If you ever have any questions about Opaleye I'm happy to help. Feel free to open an issue to ask about anything any time.

Sounds like Opaleye isn't on your list of choices, but if it is then feel free to ask me any questions, any time by filing an issue (I'm the Opaleye maintainer).

Opaleye is Posgres-only, and Postgres does such a good job of optimizing queries that performance issues basically don't arise. I have a long-standing invitation to improve Opaleye's query generation as soon as anyone can produce a repeatable example of a poorly-performing query. In Opaleye's eight years, no one ever has. There's a thread where two reports have come close, but it's still not clear that that's simply due to using a six year old version of Postgres.

Nice! Well done. If you have any more questions about product-profunctors or Opaleye then please let me know. It's best to ask by [opening an issue](https://github.com/tomjaguarpaw/haskell-opaleye/issues/new).

The only way out that I can see is to design embedded domain specific languages (EDSLs) that inherit the expressiveness, composability and type safety from the host language. That's what Opaleye and Rel8 (Postgres EDSLs for Haskell do. Haskell is particularly good for this. The query language can be just a monad and therefore users can carry all of their knowledge of monadic programming to writing database queries.

This approach doesn't resolve all of the author's complaints but it does solve many.

Disclaimer: I'm the author of Opaleye. Rel8 is built on Opaleye. Other relational query EDSLs are available.

[1] https://github.com/tomjaguarpaw/haskell-opaleye/

For an example of how this plays out in practice observe Opaleye's MaybeFields (generously contributed by Shane and /u/ocharles at Circuithub). The definition is essentially identical to Optional from the paper. Instead of a specialised typeclass Inhabited we use the ProductProfunctor NullSpec (which happens to conjure up an SQL NULL, but it could be any other witness).

Writing Haskell programs that rely on third-party packages is still an issue when it’s a not actively maintained package. They get out of date with the base library (Haskell’s standard library), and you might see yourself in a situation where you need to downgrade to an older version. This is not exclusive to Haskell, but it happens more often than I’d like to assume. However, if you only rely on known well-maintained libraries/frameworks such as Aeson, Squeleto, Yesod, and Parsec, to name a few, it’s unlikely you will face troubles at all, you just need to be more mindful of what you add as a dependency. There’s stackage.org now, a repository that works with Stack, providing a set of packages that are proven to work well together and help us to have reproducible builds in a more manageable way—not the solution for all the cases but it’s good to have it as an option.

However, we can use Esqueleto (”a bare bones, type-safe EDSL for SQL queries”) with Persistent's serialization to write type-safe SQL queries. It’s unlikely that you want to use Persistent by itself with SQL, so let’s use and review them together.

Postgresql-simple is a great library, it makes a nice use of overloaded strings to do the job. Some other nice libraries to keep an eye on are opaleye (postgres specific, which is equally nice but could be a bit difficult to get why the types are so big) and a combination of persistent (not DB specific! can work on postgres, sqlite, but also noSQL DBs like mongo, it's still easy to learn but you lose some things, such as joins due to the power of being agnostic) + esqueleto for type safe joins (be sure to look up the experimental package, it's a more comfortable syntax that will soon become the default one).

Using esqueleto in one of my haskell projects was a huge time sink and a major barrier to entry for colleagues.

In Haskell: https://hackage.haskell.org/package/esqueleto

Either it analyzes the given SQL to determine the in/out types of each SQL query, or it calls the database describe feature at compile-time.