mysql (hsql-mysql-1.7) on Linux with GHC 8.3 - cabal issues
Hello, I had some difficulty building hsql and hsql-mysql (native driver) packages under GHC 8.3 on Fedora 9. Namely, they do not install with cabal install, because of a few API changes. Is this considered all right as GHC 8.3 is still experimental, or should the packages be updated? If so, can somebody please do it. I love when things just work with cabal install! The problem looks very basic -- just some Cabal file incompatibilities. However I am not experienced with the Cabal build process, so I'll just write what I did to get it to work on my platform, maybe it will help someone. == hsql.cabal == name: hsql version: 1.7 license: BSD3 author: Krasimir Angelov <ka2_mail@yahoo.com> category: Database description: Simple library for database access from Haskell. exposed-modules: Database.HSQL, Database.HSQL.Types build-depends: base, old-time build-type: Simple ghc-options: -O2 extensions: ForeignFunctionInterface, TypeSynonymInstances, CPP, RankNTypes, DeriveDataTypeable == hsql-mysql.cabal == name: hsql-mysql version: 1.7 license: BSD3 author: Krasimir Angelov <kr.angelov@gmail.com> category: Database description: MySQL driver for HSQL. ghc-options: -O2 build-depends: base, hsql, Cabal, old-time extensions: ForeignFunctionInterface, CPP include-dirs: Database/HSQL, /usr/include/mysql build-type: Simple extra-source-files: Database/HSQL/HsMySQL.h extra-libraries: mysqlclient extra-lib-dirs: /usr/lib/mysql exposed-modules: Database.HSQL.MySQL == hsql-mysql*/Setup.lhs == #!/usr/bin/runghc \begin{code} import Distribution.Simple main = defaultMain \end{code} Of course this hsql-mysql.cabal should not mention Fedora-specific locations as /usr/lib/mysql and /usr/include/mysql but I don't know how to make that generic. The original version had a big custom Setup.lhs file which wouldn't compile with the new Cabal and which I couldn't tweak myself. Thanks, --A
On Thu, 2008-10-02 at 17:37 +0300, Anton Tayanovskyy wrote:
Hello,
I had some difficulty building hsql and hsql-mysql (native driver) packages under GHC 8.3 on Fedora 9. Namely, they do not install with cabal install, because of a few API changes. Is this considered all right as GHC 8.3 is still experimental, or should the packages be updated? If so, can somebody please do it. I love when things just work with cabal install!
The problem here really is that HSQL has no maintainer and has not been updated for about two years if my memory serves me correctly. Some distros, Fedora, Gentoo etc have patched HSQL to keep it working with ghc-6.8. The answer is to find someone to maintain it, take over maintenance yourself or switch to another lib like hdbc or takusen. Duncan
On Thu, Oct 2, 2008 at 6:39 PM, Duncan Coutts <duncan.coutts@worc.ox.ac.uk> wrote:
The problem here really is that HSQL has no maintainer and has not been updated for about two years if my memory serves me correctly. Some distros, Fedora, Gentoo etc have patched HSQL to keep it working with ghc-6.8.
I see. True, it was updated Apr 9, 2007. Well, it's a pity that neither Hackage nor the Haskell wiki mentions those patches.
The answer is to find someone to maintain it, take over maintenance yourself or switch to another lib like hdbc or takusen.
Hmm.. That's too bad. AFAIK hdbc and takusen do not have native MySQL backends. Last time I tried working with MySQL through ODBC on Linux it was quite slow to connect, compared to the native backend. Taking over myself is out of question, it is beyond me. So by elimination I'll have to find someone! --A
On Fri, Oct 03, 2008 at 12:14:18AM +0300, Anton Tayanovskyy wrote:
On Thu, Oct 2, 2008 at 6:39 PM, Duncan Coutts <duncan.coutts@worc.ox.ac.uk> wrote:
The problem here really is that HSQL has no maintainer and has not been updated for about two years if my memory serves me correctly. Some distros, Fedora, Gentoo etc have patched HSQL to keep it working with ghc-6.8.
I see. True, it was updated Apr 9, 2007. Well, it's a pity that neither Hackage nor the Haskell wiki mentions those patches.
The answer is to find someone to maintain it, take over maintenance yourself or switch to another lib like hdbc or takusen.
Hmm.. That's too bad. AFAIK hdbc and takusen do not have native MySQL backends. Last time I tried working with MySQL through ODBC on Linux it was quite slow to connect, compared to the native backend. Taking over myself is out of question, it is beyond me. So by elimination I'll have to find someone!
It is true that HDBC does not have a native MySQL backend. However, you should not notice a significant performance change with ODBC. There are a lot of variables that can come into play with ODBC, though, such as your local configuration, whether you set it up to use TCP, which ODBC package you are using, etc. What's more, HDBC has a stronger and more versatile API than HSQL, which permits even more speed improvements. Features such as precompiled queries can be huge for many apps, as can referencing result columns as an ordered list instead of an association list or map. Personally, I spent the time to write the Sqlite3, ODBC, and PostgreSQL bindings for HDBC owing to existing needs. I have no need for a MySQL binding because I avoid MySQL wherever possible, and where not possible, use ODBC. That said, the API is designed to make development of database backends easy. FFI also is quite nice. It should not be a significant task for an interested party to write a MySQL backend. I think it has not happened yet because the ODBC backend is fully functional for MySQL. -- John
John, Thank you for your reply. I benchmarked HDBC.ODBC with MySQL and it is indeed working well. So whatever slow results I used to get were due to that particular setup. It looks that HDBC will suit my needs as well. Thanks, --A
What's more, HDBC has a stronger and more versatile API than HSQL, which permits even more speed improvements. Features such as precompiled queries can be huge for many apps, as can referencing result columns as an ordered list instead of an association list or map.
Personally, I spent the time to write the Sqlite3, ODBC, and PostgreSQL bindings for HDBC owing to existing needs. I have no need for a MySQL binding because I avoid MySQL wherever possible, and where not possible, use ODBC.
That said, the API is designed to make development of database backends easy. FFI also is quite nice. It should not be a significant task for an interested party to write a MySQL backend. I think it has not happened yet because the ODBC backend is fully functional for MySQL.
-- John
participants (3)
-
Anton Tayanovskyy -
Duncan Coutts -
John Goerzen