[Haskell-cafe] HDBC's future and request for help

[Chris Dornan]

Hi John,

Two thoughts: is there any prospect of making HDBC available under a
BSD-like license? The LGPL license is a significant barrier for me and I
expect it will be for others.

And, along the lines of your own comments, the ODBC interface raises a
significant (technical) barrier for MySQL users. Is there any chance that we
can encourage/help getting the the MySQL driver closer to production
quality?

I expect to be able to help out with this (and a CentOS HP) later in the
year, provided I can resolve the license issue!

Cheers,

Chris

On 22 February 2011 16:50, John Goerzen <jgoerzen at complete.org> wrote:

> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110222/69c2b77e/attachment.htm>