Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)
oleg@pobox.com wrote:
Incidentally, the difficulty with finalizers was precisely the argument for using enumerators rather than cursors in database APIs. Takusen has implemented that idea; takusen currently supports Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test shows that takusen can retrieve 2 million rows from a table without running out of memory.
The differences between HDBC and HSQL have been recently discussed. Where does Takusen fit into this picture? From the above, it sounds like it has quite a different API. Are all 3 of these actively maintained? As someone who may wish to construct a haskell db binding for a new db, it's not clear to which API it should conform. Sometimes choice is a burden... Tim
There are three active database libraries: HDBC, HSQL and Takusen. It is quite disappointing from my point of view. Recently there was the same situation with the GUI libraires. The Haskell Community is quite small to waste efforts, developing different libraries for the same things. When I started with HSQL there were only two database libraries: HaSQL for ODBC and libpq for PostgreSQL. They both are dead, I think. I decided that it is useful to have one abstract API that can cover all database bindings. I imagine something like JDBC, ADO or DBI for Haskell. If you guys would like this to happen then lets discuss what we want. I would be happy to work on single project that can satisfy all needs. Cheers, Krasimir 2006/1/10, Tim Docker <timd@macquarie.com.au>:
oleg@pobox.com wrote:
Incidentally, the difficulty with finalizers was precisely the argument for using enumerators rather than cursors in database APIs. Takusen has implemented that idea; takusen currently supports Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test shows that takusen can retrieve 2 million rows from a table without running out of memory.
The differences between HDBC and HSQL have been recently discussed. Where does Takusen fit into this picture? From the above, it sounds like it has quite a different API. Are all 3 of these actively maintained?
As someone who may wish to construct a haskell db binding for a new db, it's not clear to which API it should conform. Sometimes choice is a burden...
Tim
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Erm, has nobody replied to this yet? I want a robust interface, that uses bracket notation all the way down, so that any error is caught and resources are freed appropriately without the use of finalizers (which may not get run and lead to resource starvation - they are not reliable if dealing with many connections, unless you start forcing garbage collections). I want a simple interface (as few functions as possible to do the job) and robust exception handling. I certainly like the idea of using runST to encapsulate the DbHandle... and infact the DB code I have does this, but not in a systematic way... I guess really all allocated handles that are passed to user defined functions need to be protected in this way. The code I wrote is really to support a relational algebra layer over the top... When I developed this there were no database drivers that worked under linux, as HSQL only supported ODBC under windows, so I developed an ODBC specific layer myself tested with unixODBC and iODBC. So IMHO, braket notation, STRef encapsulation, no finalizers, lots of exception handling, minimal interface. I would sacrifice some speed for simplicity of interface... Keean Krasimir Angelov wrote:
There are three active database libraries: HDBC, HSQL and Takusen. It is quite disappointing from my point of view. Recently there was the same situation with the GUI libraires. The Haskell Community is quite small to waste efforts, developing different libraries for the same things. When I started with HSQL there were only two database libraries: HaSQL for ODBC and libpq for PostgreSQL. They both are dead, I think. I decided that it is useful to have one abstract API that can cover all database bindings. I imagine something like JDBC, ADO or DBI for Haskell. If you guys would like this to happen then lets discuss what we want. I would be happy to work on single project that can satisfy all needs.
Cheers, Krasimir
2006/1/10, Tim Docker <timd@macquarie.com.au>:
oleg@pobox.com wrote:
Incidentally, the difficulty with finalizers was precisely the argument for using enumerators rather than cursors in database APIs. Takusen has implemented that idea; takusen currently supports Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test shows that takusen can retrieve 2 million rows from a table without running out of memory.
The differences between HDBC and HSQL have been recently discussed. Where does Takusen fit into this picture? From the above, it sounds like it has quite a different API. Are all 3 of these actively maintained?
As someone who may wish to construct a haskell db binding for a new db, it's not clear to which API it should conform. Sometimes choice is a burden...
Tim
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On 2006-01-14, Keean Schupke <k.schupke@imperial.ac.uk> wrote:
Erm, has nobody replied to this yet? I want a robust interface, that uses bracket notation all the way down, so that any error is caught and resources are freed appropriately without the use of finalizers (which may not get run and lead to resource starvation - they are not reliable
To be sure, your only failure situation in this case is if you're dealing with many connections *and* creating/destroying them frequently. Hopefully you wouldn't be.
if dealing with many connections, unless you start forcing garbage collections). I want a simple interface (as few functions as possible to do the job) and robust exception handling.
HDBC will let you manually close (and free) database objects. If you don't manually do that, they will be automatically closed/freed at garbage collection time. It uses a small C wrapper to make this happen correctly. It doesn't have built-in support for bracketing things all the way down, but functions to do that are already in the testsuite. It would be trivial to add them to HDBC proper, since there is robust exception handling all through. The HDBC API is at: http://darcs.complete.org/hdbc/doc/Database-HDBC.html I didn't honestly follow the STRef discussion, or how something so I/O-based could work there. -- John
John wrote:
On 2006-01-14, Keean Schupke <k.schupke@imperial.ac.uk> wrote:
Erm, has nobody replied to this yet? I want a robust interface, that uses bracket notation all the way down, so that any error is caught and resources are freed appropriately without the use of finalizers (which may not get run and lead to resource starvation - they are not reliable
To be sure, your only failure situation in this case is if you're dealing with many connections *and* creating/destroying them frequently.
Hopefully you wouldn't be.
You could be using connection pooling in the database driver or ODBC layer... Here the minimal overhead of opening/closing allows you to use a "bracket" within each connection, rather than around the whole server. Besides which the goal is not just to be safe in practice, but to be theoretically safe in all circumstances. If you allow the programmer to shoot themselves in the foot, then they often will (for example memory management and buffer overflows)... Its no good to partly remove responsibility, as that makes bugs more likely not less likely (If the programmer has to deal with an opaque system with flaws, unless the programmer is highly aware of those flaws they will take no account of them in their coding). The only way you can give the programmer a genuine black box to play with, is if it is theoretically safe, then the programmer can (ab)use it how they wish without accidentally breaking the conditions of usage. Regards, Keean.
On Tuesday 17 January 2006 16:08, Keean Schupke wrote:
John wrote:
On 2006-01-14, Keean Schupke <k.schupke@imperial.ac.uk> wrote:
Erm, has nobody replied to this yet? I want a robust interface, that uses bracket notation all the way down, so that any error is caught and resources are freed appropriately without the use of finalizers (which may not get run and lead to resource starvation - they are not reliable
To be sure, your only failure situation in this case is if you're dealing with many connections *and* creating/destroying them frequently.
Hopefully you wouldn't be.
You could be using connection pooling in the database driver or ODBC layer... Here the minimal overhead of opening/closing allows you to use a "bracket" within each connection, rather than around the whole server. Besides which the goal is not just to be safe in practice, but to be theoretically safe in all circumstances. If you allow the programmer to shoot themselves in the foot, then they often will (for example memory management and buffer overflows)... Its no good to partly remove responsibility, as that makes bugs more likely not less likely (If the programmer has to deal with an opaque system with flaws, unless the programmer is highly aware of those flaws they will take no account of them in their coding). The only way you can give the programmer a genuine black box to play with, is if it is theoretically safe, then the programmer can (ab)use it how they wish without accidentally breaking the conditions of usage.
I agree most strongly. Furthermore, as a /user/ of a library, what I want is simple semantics and guarantees are always simpler than side conditions, "take care when doing this or that", etc.. I just don't want to have to care about such stuff. Also, to make things easier one often choses bad programming style ("defensive programming") in order to avoid the complex reasoning necessary to ensure that the program "behaves well". For instance, it is tempting to encapsulate the whole program into the 'withDB' bracket, instead of only the part that actually uses the DB connection, just to be on the safe side. If the type system catches this kind of errors, one is encouraged to restrict the scope of the DB connection (or whatever), resulting in earlier freeing of resources and better modularity. Ben
participants (5)
-
Benjamin Franksen -
John Goerzen -
Keean Schupke -
Krasimir Angelov -
Tim Docker