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