
"John" == John Goerzen
writes:
Hello John, 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 John> them. 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 [1]. 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 Takusen devs... 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... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------