[Haskell-cafe] Re: databases in Haskell & type-safety
gour at mail.inet.hr
Fri Jan 9 04:25:15 EST 2009
>>>>> "John" == John Goerzen <jgoerzen at complete.org> writes:
John> I would say that database interactions are typically limited to a
John> small part of code. In small programs, I generally have a DB
John> module that does the queries, and marshals everything to/from the
John> rich Haskell types I define. Any possible type issues are thus
John> constrained to that small part of code.
That's right. However, I envision application for which a significant
part would require querying (kind of research base for querying common
stuff in thousands of records.)
John> HDBC is a low-level abstraction, which can be used on its own or,
John> of course, as a layer underlying HaskellDB or some such. I do not
John> dispute the use of tools such as HaskellDB or others that try to
John> automate the business of representing a database's schema -- and
John> queries against it -- using a language's type system. There are a
John> lot of these systems in a lot of languages. I've used some of
Have you maybe tried Takusen (HaskellDB which you reference above does
not seem very much alive)?
John> And, almost universally, they annoy me. I find it takes longer to
John> write code with them than without, and often they have issues
John> representing some query that I know I can do easily in SQL but
John> maybe can't as easy in the toolkit. As an example, when I last
John> looked at HaskellDB in 2005, I found that it was impossible to do
John> a SELECT without a DISTINCT . There are many situations where
John> such a thing is necessary, so I had to discard it for my projects.
Hmm, that's interesting to hear...I'm curious what could be reply from
John> HDBC is more similar to Perl's DBI or Python's DB-API (or perhaps
John> a sane version of JDBC). It is a standard interface to SQL RDBMS
John> engines that provides some tools for marshaling data back and
John> forth, but generally leaves you to construct the queries.
Well, that's not too bad...
John> So, this was not intended as an HDBC commercial, just more of a
John> braindump as to why I wrote it. Hope it helps.
Sure, it helps. Thanks a lot for your input.
Otoh, I believe that, considering it is mentioned in RWH, HDBC does not
need much commercial, just contrary, you can expect new feature requests
From the new army of Haskell developers cultivated by the book :-)
I'll e.g. open ticket for BLOB support :-D
John> HDBC is actively used in mission-critical applications where I
John> work. We use both the PostgreSQL and ODBC backends in production.
John> We even use the ODBC backend along with the particularly nefarious
John> ODBC interface for the Progress 4GL database. I use the Sqlite3
John> backend quite a bit in my own personal projects, such as hpodder
John> and twidge.
Database abstraction offered by HDBC is very nice feature allowing one
to change back-end driver without too much hassle, so I'll try to
investigate a bit about possible BLOB support on HDBC-level.
It's definitely something used in real-world databases...
Gour | Zagreb, Croatia | GPG key: C6E7162D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/5c8a80fa/attachment.bin
More information about the Haskell-Cafe