[Haskell-cafe] databases in Haskell & type-safety

[John Goerzen]

On Sat, Jan 03, 2009 at 10:48:44AM +0100, Gour wrote:

> So, considering that HDBC nicely abstracts API enabling one to easily
> switch from e.g. Sqlite3 to Postgres, and it is used as in example for
> database programming, it seems as logical (and the only) choice for
> Haskell database programming in a real-world?

Sorry to come to this late, but I figured I'd jump in a bit, as
someone that uses HDBC in the real world.

I would say that database interactions are typically limited to a
small part of code.  In small programs, I generally have a DB module
that does the queries, and marshals everything to/from the rich
Haskell types I define.  Any possible type issues are thus constrained
to that small part of code.

HDBC is a low-level abstraction, which can be used on its own or, of
course, as a layer underlying HaskellDB or some such.  I do not
dispute the use of tools such as HaskellDB or others that try to
automate the business of representing a database's schema -- and
queries against it -- using a language's type system.  There are a lot
of these systems in a lot of languages.  I've used some of them.

And, almost universally, they annoy me.  I find it takes longer to
write code with them than without, and often they have issues
representing some query that I know I can do easily in SQL but maybe
can't as easy in the toolkit.  As an example, when I last looked at
HaskellDB in 2005, I found that it was impossible to do a SELECT
without a DISTINCT [1].  There are many situations where such a thing
is necessary, so I had to discard it for my projects.

HDBC is more similar to Perl's DBI or Python's DB-API (or perhaps a
sane version of JDBC).  It is a standard interface to SQL RDBMS
engines that provides some tools for marshaling data back and forth,
but generally leaves you to construct the queries.  It does not really
solve the same problem as HaskellDB.

I wrote HDBC because of some issues with HSQL.  I had trouble with
segfaults, referencing returned data by column number instead of name,
and it did not support replacable parameters.  HDBC supports all of
that, and as a result, does not provide any functions to escape data
for a SQL engine because its design renders such functions
unnecessary.  I have not followed HSQL development since.

So, this was not intended as an HDBC commercial, just more of a
braindump as to why I wrote it.  Hope it helps.

HDBC is actively used in mission-critical applications where I work.
We use both the PostgreSQL and ODBC backends in production.  We even
use the ODBC backend along with the particularly nefarious ODBC
interface for the Progress 4GL database.  I use the Sqlite3 backend
quite a bit in my own personal projects, such as hpodder and twidge.

> I'm not familiar with Takusen which says: "Takusen's unique selling
> point is safety and efficiency..." and I would appreciate if someone
> could shed some more light to its 'safety' and the present status?

[1] http://www.haskell.org/pipermail/haskell-cafe/2005-August/011026.html

-- John