I've been using Takusen for all of my database needs, which most of the time means interfacing to a PostgreSQL database, and it has worked out pretty well in practice. In fact, I experimented with hsql and HDBC a while back and for some reason I can't remember they turned out to be less convenient than Takusen so I changed the code I was working on back over to Takusen. Cheers, Greg On 7/7/10 2:17 AM, Nick Rudnick wrote:

Hi Chris,

these are good questions -- actually, you might have mentioned Takusen, too.

Clearly, HDBC is the largest of these projects, and there are lots of things well done there.

Takusen has an interesting approach, and I would like to see a discussion here about the practical outcomes, as I have done no testing yet.

I myself quite a time ago had an opportunity to do a Haskell job with a PostgreSQL backend for a client, where I tried out all three and got hsql running easiest. A maintainer was vacant, so I stepped in happily -- doing refactorings, fixing problems at request, giving advice to people.

I can say that I am quite a little PostgreSQL centric and that I have a GIS project in sight, for which I want to try to adapt hsql.

Cheers,

Nick

Christopher Done wrote:

...

One thing that would be nice is a unification of the general database libraries hsql and HDBC. What is the difference between them? Why are there two, and why are there sets of drivers for both (duplication of effort?)? I've used both in the past but I can't discern a real big difference (I used the hsql-sqlite library and the HDBC-postgresql library, whichever worked...). It seems the best thing to do is either actively merge them together and encourage the community to move from one to the other -- judging from what I've read HDBC is more up to date and newer than hsql -- or have some documentation with damn good reasons to choose one or the other, because currently this is a needless source of confusion and possible duplication of effort for Haskell's database libraries.

I wasn't going to post until I'd actually researched the difference myself properly but I didn't get chance to have a look over the weekend, but I thought I'd pose the question. Do people actually care about this? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

FWIW, +1. Sorry for not speaking up sooner, I just don't have much to add: of the three, I've only used HDBC. Michael On Wed, Jul 7, 2010 at 8:44 PM, Christopher Done wrote:

I did try Takusen with PostgreSQL and it worked perfectly for me, too. The only reason I'm using HDBC is because there was already a HaskellDB HDBC driver. I was considering writing a Takusen driver for HaskellDB, in fact (if possible).

Anyway, the point remains, we need a single goto database library. I don't know if Takusen's left-fold typeable way of doing things is different enough to disqualify it from The Great Merge or not. Though the lack of response to this thread makes me think no one particularly thinks this is a problem. Is it worth the effort having one very high quality stable library instead of three fairly okay not-really-that-different maybe-working libraries?

On 7 July 2010 19:29, Gregory Crosswhite wrote:

...

I've been using Takusen for all of my database needs, which most of the time means interfacing to a PostgreSQL database, and it has worked out pretty well in practice. In fact, I experimented with hsql and HDBC a while back and for some reason I can't remember they turned out to be less convenient than Takusen so I changed the code I was working on back over to Takusen.

Cheers, Greg

On 7/7/10 2:17 AM, Nick Rudnick wrote:

...

Hi Chris,

these are good questions -- actually, you might have mentioned Takusen, too.

Clearly, HDBC is the largest of these projects, and there are lots of things well done there.

Takusen has an interesting approach, and I would like to see a

discussion

...

here about the practical outcomes, as I have done no testing yet.

I myself quite a time ago had an opportunity to do a Haskell job with a PostgreSQL backend for a client, where I tried out all three and got hsql running easiest. A maintainer was vacant, so I stepped in happily -- doing refactorings, fixing problems at request, giving advice to people.

I can say that I am quite a little PostgreSQL centric and that I have a GIS project in sight, for which I want to try to adapt hsql.

Cheers,

Nick

Christopher Done wrote:

...

One thing that would be nice is a unification of the general database libraries hsql and HDBC. What is the difference between them? Why are there two, and why are there sets of drivers for both (duplication of effort?)? I've used both in the past but I can't discern a real big difference (I used the hsql-sqlite library and the HDBC-postgresql library, whichever worked...). It seems the best thing to do is either actively merge them together and encourage the community to move from one to the other -- judging from what I've read HDBC is more up to date and newer than hsql -- or have some documentation with damn good reasons to choose one or the other, because currently this is a needless source of confusion and possible duplication of effort for Haskell's database libraries.

I wasn't going to post until I'd actually researched the difference myself properly but I didn't get chance to have a look over the weekend, but I thought I'd pose the question. Do people actually care about this? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Anyway, the point remains, we need a single goto database library.

Though the lack of response to this thread makes me think no one particularly thinks this is a problem.

This is an interesting problem. For my part, I suspect the proliferation of high-level database libraries is going to continue. If you were to convince the present package maintainers to pitch in and build a Grand Database Library, inevitably someone would come along and build another one for whatever reason. Also, I don't think the dust has settled on techniques for database access in Haskell in any case, even for RDBMSs in particular. Since I couldn't agree more that duplication of effort is a sad thing, I think a good place to start is for people to write database library binding-only packages that get used by higher-level libraries like HDBC and Takusen. Such libraries should include memory management hooks specific to the sematics of the engine in question. There are a couple of libraries for this on Hackage already, but they don't appear to be used by any of the high-level database abstraction libraries. Otherwise I'd ask: what qualifies as a "go-to" library? Which users should it satisfy? How accessible should it be? Most answers I can think of lead me to believe enough people will be put off by it that other libraries will pop up. :) -- Jonathan Daugherty

...

Anyway, the point remains, we need a single goto database library.

Though the lack of response to this thread makes me think no one particularly thinks this is a problem.

This is an interesting problem. For my part, I suspect the proliferation of high-level database libraries is going to continue. If you were to convince the present package maintainers to pitch in and build a Grand Database Library, inevitably someone would come along and build another one for whatever reason. Also, I don't think the dust has settled on techniques for database access in Haskell in any case, even for RDBMSs in particular.

For what it's worth, I would be happy to get persistent[1] behind a Grand Database Library. Right now, the PostgreSQL backend[2] is built on HDBC while the SQLite backend[3] includes a variant of the direct-sqlite

On Wed, Jul 7, 2010 at 9:46 PM, Jonathan Daugherty wrote: package[4]. Here's my two cents on why I didn't run with HDBC for both: * I wanted the SQLite backend to be the default backend that anyone could use, without library dependencies. It would be nice if HDBC-sqlite3 had an option to build against the sqlite3 amalgamation instead of system libraries. (In fact, it would be cool if that were the default, and system libraries the option.) * I'm not fond of the Convertible typeclass. In particular, it makes no distinction between conversions which are guaranteed to succeed (Int -> String) and conversions which might fail (String -> Int). As a result, the fromSql function can easily throw a runtime error. (For that matter, toSql could as well, but that is much less likely.) * I would like to be able to explicitly finalize statements. I believe I've gotten some exceptions in the past when trying to close a database connection because some statements were not finalized, but I can't remember the details right now. * I don't like that the lazy versions of functions are the default, and you have to add the ' for strict. It's too easy to make mistakes with the results of a lazy database query. I would even go so far as to recommend removing them entirely, but I think most people will not like that. Overall, I think HDBC is a great library, but I have no experience with the alternatives. The idea of breaking things into low-level C bindings and higher-level stuff on top is great. Michael [1] http://hackage.haskell.org/package/persistent [2] http://hackage.haskell.org/package/persistent-postgresql [3] http://hackage.haskell.org/package/persistent-sqlite [4] http://hackage.haskell.org/package/direct-sqlite

joerg.rudnick:

Hi Chris,

these are good questions -- actually, you might have mentioned Takusen, too.

Clearly, HDBC is the largest of these projects, and there are lots of things well done there.

Takusen has an interesting approach, and I would like to see a discussion here about the practical outcomes, as I have done no testing yet.

It has been used in production at a number of places, including Galois.

I myself quite a time ago had an opportunity to do a Haskell job with a PostgreSQL backend for a client, where I tried out all three and got hsql running easiest. A maintainer was vacant, so I stepped in happily -- doing refactorings, fixing problems at request, giving advice to people.

I can say that I am quite a little PostgreSQL centric and that I have a GIS project in sight, for which I want to try to adapt hsql.

And you have to be wary about the license of HDBC (LGPL) if you want to use the package in software you redistribute (though this is rarely the case for database apps, I'm guessing). Satisfying the linking requirements with GHC -O2 are non-trivial, even with -dynamic. -- Don

On Wed, Jul 21, 2010 at 12:20 AM, John Goerzen wrote:

On 07/07/2010 03:22 PM, Don Stewart wrote:

And you have to be wary about the license of HDBC (LGPL) if you want to

...

use the package in software you redistribute (though this is rarely the case for database apps, I'm guessing). Satisfying the linking requirements with GHC -O2 are non-trivial, even with -dynamic.

I remain ready to have a discussion with anyone that has a problem with that. I've had one or two people ask me about it in the past, but they never followed up to my reply mails. I'm not going to be a stick in the mud about LGPL, but neither do I want to allow others to commercialize/embrace-and-extend HDBC without giving back to the community. My intent isn't to get in the way of people using HDBC in their own software, whether commercial or proprietary, but to prevent proprietarization of HDBC itself. I suspect LGPL+some exemption could solve any concerns and would be happy to pursue it.

I think a simple statement along the lines of the GNU Classpath linking exception would go very far[1]. I only mention that one since it's quoted verbatim on the Wikipedia site.

Michael [1] http://en.wikipedia.org/wiki/GPL_linking_exception#The_classpath_exception

John Goerzen writes:

I need to read the LGPL and analyze it closer, but my first analysis suggests that this would work fine for me and others.

I'm using the LGPL for library code, and GPL for applications. Although a lot of noise is generated from the linking issues, the most imporant point to me is that LGPL allows you to use the library in other open source (but non-GPL-compliant) applications. Binary/commercial/proprietary software - well, I'll worry about it the day it happens. So far, nobody ever asked for a BSD license - but I'd be happy about an exception (even with modifications to the library, as long as those modifications were available).

I'll also want to evaluate LGPL v3, which I have been meaning to move to anyhow.

Please report back if you do! -k -- If I haven't seen further, it is by standing in the footprints of giants

Vo Minh Thu writes:

For a LGPL library, why do you make the distinction between open source and proprietary applications? They can all link to a LGPL library.

The "problem" with the LGPL is that in order to distribute a program using an LGPL library, the recipient must be allowed to replace the LGPL'ed component with a modified version. When source is available, this is not a problem, of course. For closed source software, this can be solved by having the LGPL bit be a dynamic/shared library, or by distributing the rest of the application as a set of .o files, allowing recipients to relink the application themselves. Both of these approaches are problematic with the current state of GHC. -k -- If I haven't seen further, it is by standing in the footprints of giants