[Haskell-cafe] databases in Haskell & type-safety
Hi! I'd like to use sqlite3 as application storage in my haskell project... Browsing the available database options in Haskell it seems that: a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10) b) haskelldb is also not in a good shape - build fails with 6.8 & 6.10 For Haskell-newbie as myself, it looks that haskelldb is the one which provide(ed)s the most secure API (I was reading draft paper about MetaHDBC but, apparently, the type inference support in open-source databases is poor and that's why, according to the author "This is unfortunately as it makes MetaHDBC a lot less valuable." What remains is: c) Takusen which is also not up-to-date (it fails with 6.10) and d) HDBC and sqlite bindings which are the only packages which build with 6.10. However options in d) do not offer, afaik, type-safety which is emblem of Haskell language, so I wonder how much this could be the problem for real-world usage? 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? 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? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpECYShrDstY.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] databases in Haskell & type-safety
Excerpts from Gour's message of Sat Jan 03 03:48:44 -0600 2009: > Hi! > > I'd like to use sqlite3 as application storage in my haskell project... > > Browsing the available database options in Haskell it seems that: > > a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10) > > b) haskelldb is also not in a good shape - build fails with 6.8 & 6.10 > > For Haskell-newbie as myself, it looks that haskelldb is the one which > provide(ed)s the most secure API (I was reading draft paper about > MetaHDBC but, apparently, the type inference support in open-source > databases is poor and that's why, according to the author "This is > unfortunately as it makes MetaHDBC a lot less valuable." > > What remains is: > > c) Takusen which is also not up-to-date (it fails with 6.10) and > > d) HDBC and sqlite bindings which are the only packages which build with > 6.10. Have you tried the simple sqlite3 bindings available? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite > 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? Takusen is based on the (unique) concept of a left-fold enumerator. Having a left-fold interface guarantees timely (nearly perfect, really) deallocation of resources while still having the benefits of a 'lazy' stream. This interface has (as shown by Oleg and others) proven to be very efficient in a number of cases as well as favorable for many. The idea is very novel, and truly worth exploring if you ask me. For more information about left-fold enumerators and takusen, see here: http://okmij.org/ftp/papers/LL3-collections-enumerators.txt http://okmij.org/ftp/Haskell/fold-stream.lhs http://okmij.org/ftp/Haskell/misc.html#takusen NB: I have *just* (about 5 minutes ago) sent in a patch for takusen to get it to build on GHC 6.10.1 to Oleg. Hopefully an updated version will appear on hackage in the next few days. Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] databases in Haskell & type-safety
Gour schrieb: > Hi! > > I'd like to use sqlite3 as application storage in my haskell project... > > Browsing the available database options in Haskell it seems that: > > a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10) No, it is maintained by frede...@ofb.net . I have also contributed Oracle/OCI code a half year ago. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] databases in Haskell & type-safety
On Sat, Jan 3, 2009 at 4:25 AM, Austin Seipp wrote: > NB: I have *just* (about 5 minutes ago) sent in a patch for takusen > to get it to build on GHC 6.10.1 to Oleg. Hopefully an updated version > will appear on hackage in the next few days. Yay! Thanks. I've been waiting. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] databases in Haskell & type-safety
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
