John Goerzen wrote:

On 2005-08-18, Brian Strand wrote:

...

I'm thinking about (re)writing some perl code in Haskell (for performance and correctness reasons). Has anyone done much with Oracle and Haskell? So far

Not Oracle specifically, but other databases, both free and proprietary.

...

Before I wade in too deep, I'm wondering if anyone has done much "business app" programming with Haskell (where "business app" is rather fuzzily defined as database access, web UIs, interfacing with various systems over ip, etc.). Does anyone have any advice? eg "don't go there" or "works great!" or "try OCaml" :) .

I'm doing a lot of it. There's a good deal of web and database activity going on here. Haskell is also my language of choice for scripting projects, especially data transfer (thanks in part to my FTP library in MissingH <g>)

I'm glad to hear that there are other people (or at least one other person, depending on what you meant by "here"...) doing this kind of thing; judging by the list traffic you'd think almost no one uses Haskell with a RDBMS.

I use HSQL for everything database-related. HaskellDB did not work out well. It proved rather buggy, cumbersome, inflexible (it appeared to be impossible to do a "SELECT" without "DISTINCT"), and poorly-scalable (try having it scan a database with several thousand tables).

HSQL is more low-level, but I'm comfortable with that, having used Perl's DBI and Python's DB-API before.

This (Perl DBI, ODBC, JDBC) is my background as well; if I can fire SQL at it, that's most of the way there.

HSQL natively supports the common Free databases (MySQL, PostgreSQL, SQLite, etc.) We use PostgreSQL for everything that we can. It's no less speedy than MySQL when correctly tuned, and far more reliable. It also seems to be a heck of a lot easier to install and work with than Oracle ;-)

Oracle is indeed a pain to install, although it has gotten better with recent versions. The main things keeping us on Oracle are its very good (online!) backup and recovery abilities, high-availability features, and fantastic performance tuning (the plethora of wait events and extremely detailed statistics is what I'm thinking of here). Performance-wise it has its strong and weak points.

... You didn't mention what platform you're on, but if you're on Windows, I'd imagine you'd have no problem making ODBC work. Unix is slightly more tricky, but again, I'd check out the unixODBC route. It's included in Debian by default, and I wouldn't be surprised if other OSs/distros have it too.

We run Suse 9.3 on x86 and x86-64; unixODBC does come out of the box here. If Takusen doesn't work out for some reason, I'll check into HSQL + unixODBC. Thanks for the advice, Brian

Keean Schupke wrote:

Well, I'll put my hand up, I use Haskell with databases and web stuff... Unfortunately when I started the common tools were not available. I have a home-grown Haskell-Servlet server, with monadic continuation based HTML composition and a HaskellDB like database layer. It all works very well, but being written for internal use (and me being lazy) it has only those features that I need. It is however designed as an integrated Web-Application platform... I was considering releasing it - but since I started other projects like HaskellDB restarted, WASH was written, HSQL started to support unix, and somebody added plugins to the Haskell Web-Server - So I didn't bother, although I am still using it myself...

Still I now know that HaskellDB has significant limitations, and the relational algebra approach I took is far more robust and flexable...

I don't have time to take this from a usable but incomplete project to a fully implemented API - what I mean here is that not all ODBC calls are implemented, some SQL features might be missing, some tags are not defined... not all HTTP requests and errors are generated, oh and there's no documentation. If anyone were interested in using/contributing I could give CVS access to the code.

Keean.

Yes, I'm definitely interested in evaluating/using/contributing your framework. Regards, Kyra