This seems a timely email, as I've been submitting a steady-ish
trickle of patches to HDBC-postgresql lately. Honestly, I'm rather
dissatisfied with HDBC in many respects, but I don't have a very
good idea of what a (low-level) database access library for Haskell
*should* be, and I've found HDBC to be the least worst option
available at the moment. HSQL doesn't support parameterized queries,
making SQL injection issues tedious and error prone. And while
Takusen looks rather interesting, I find the documentation and
examples lacking, I find the API a bit too esoteric for my current
tastes, and I'm fairly certain that Takusen cannot possibly work for
my application due to the way Takusen reclaims connections.
My biggest (mostly) fixable complaint with HDBC is that it hasn't
turned out to be a very complete or robust solution for accessing
databases that like to use PostgreSQL-specific features. My biggest
complaint that (probably) isn't easily fixed is it's reliance on
Convertible, and the use of lots of unsafe pattern matching and
exception-happy functions.
At least for the time being, I've found it easiest and most expedient
to fix up HDBC. I'm not particularly interested in taking over the
maintenance of HDBC, and I am comfortable with model #1 at the time
being. However if somebody else is interested in another option,
I'm probably ok with that too.
Best,
Leon
On Tue, Feb 22, 2011 at 11:50 AM, John Goerzen
Hi folks,
HDBC has been out there for quite some time now. I wrote it initially to meet some specific needs, and from that perspective, it has been done for awhile. It is clear, however, that there are some needs it doesn't meet. Most of them relate to specific backend driver items.
I'd like to start some discussion in the community about what the future of HDBC and its backend drivers ought to look like. Some models might be:
1. I continue as maintainer for HDBC and HDBC-{postgresql,odbc,sqlite3} and act as patch manager/gatekeeper for patches that are discussed on some public mailing list.
2. Interested parties adopt the backend drivers while I continue to act as maintainer/patch manager/gatekeeper for HDBC itself.
3. Interested parties adopt all of HDBC and maintain it
I am not expressing a particular preference for any of these options; just putting them forth.
Here are some of the current issues I am aware of:
1. I have no Windows development platform. I can't test the releases on Windows. Many Windows users don't have the skill to diagnose problems. These problems do eventually get fixed when a Windows user with that skill comes along -- and I appreciate their efforts very much! -- but it takes longer than it ought to.
2. The ODBC documentation is monumentally terrible, and the API is perhaps only majestically terrible, and it is not 100% clear to me all the time that I have it right. A seasoned ODBC person would be ideal here.
3. Issues exist with transferring binary data and BLOBs to/from at least PostgreSQL databases and perhaps others. There appear to be bugs in the backend for this, but BLOB support in the API may need to be developed as well.
4. Although the API supports optimizations for inserting many rows at once and precompiled queries, most backends to not yet take advantage of these optimization.
5. I have received dueling patches for whether foreign imports should be marked "safe" or "unsafe" on various backends. There seems to be disagreement in the community about this one.
6. Many interactions with database backends take place using a String when a more native type could be used for efficiency. This project may be rather complex given varying types of column data in a database -- what it expects for bound parameters and what it returns. The API support is there for it though.
7. Various other more minor items.
Thoughts?
-- John
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe