Out of curiosity, can I ask what you are actually trying to do?
I am asking because I am trying to make HAppS a reasonable replacement
for all contexts in which you would otherwise use an external relational
database except those in which an external SQL database is a specific
requirement.
-Alex-
Isto Aho wrote:
Hi,
I was also wandering between these different db-libs and thanks for your
information.
I tried several (HDBC, HSQL, HaskellDB) and made only small trials.
HaskellDB has quite many examples on wiki that gave a quick start to
further trials.
But, I wasn't able to tell that some of the fields have default values
and then it
was already time to move on to the HSQL and HDBC trials.
Is it possible to use sql-array-types with HDBC with postgresql? I don't
remember was this the
reason why I eventually tried HSQL - anyhow, it was rather difficult to
get started with HDBC
but the src test cases helped here. One example in a wiki would do
miracles :)
HSQL didn't have the array-types but it took only couple of hours to add
"a sort of" support
for those. There are some problems though... (indexed table queries
returning some nulls
is not yet working and ghci seems to be allergic to this) I was even
wondering, should I propose
a patch in some near future for this.
But if HDBC can handle those sql-arrays or if you can give a couple of
hints, how to proceed
in order to add them there, given your view below, I'd be willing to try
to help / to try to use HDBC.
br,
Isto
2007/7/30, John Goerzen <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
On 2007-07-25, George Moschovitis <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> I am a Haskell newbie and I would like to hear your suggestions
regarding a
> Database conectivity library:
>
> HSQL or HDBC ?
>
> which one is better / more actively supported?
I am the author of HDBC, so take this for what you will.
There were several things that bugged me about HSQL, if memory serves:
1) It segfaulted periodically, at least with PostgreSQL
2) It had memory leaks
3) It couldn't read the result set incrementally. That means that if
you have a 2GB result set, you better have 8GB of RAM to hold it.
4) It couldn't reference colums in the result set by position, only by
name
5) It didn't support pre-compiled queries (replacable parameters)
6) Its transaction handling didn't permit enough flexibility
I initially looked at fixing HSQL, but decided it would be easier to
actually write my own interface from scratch.
HDBC is patterned loosely after Perl's DBI, with a few thoughts from
Java's JDBC, Python's DB-API, and HSQL mixed in.
I believe it has fixed all of the above issues. The HDBC backends that
I've written (Sqlite3, PostgreSQL, and ODBC) all use Haskell's C memory
management tools, which *should* ensure that there is no memory
leakage.
I use it for production purposes in various applications at work,
connecting to both Free and proprietary databases. I also use it in my
personal projects. hpodder, for instance, stores podcast
information in
a Sqlite3 database accessed via HDBC. I have found HDBC+Sqlite3 to be a
particularly potent combination for a number of smaller projects.
http://software.complete.org/hdbc/wiki/HdbcUsers
<http://software.complete.org/hdbc/wiki/HdbcUsers> has a list of some
programs that are known to use HDBC. Feel free to add yours to it.
-- John
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org <mailto:Haskell-Cafe@haskell.org>
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
br,
Isto
------------------------------------------------------------------------
_______________________________________________
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
