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 <jgoer...@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@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
