On Fri, 2009-01-23 at 08:06 +0000, Sebastian Sylvan wrote:

2009/1/23 Galchin, Vasili Hello,

"Real World Haskell" seems to say that the abstraction layer HDBC doesn't support MySQL. If so, in what sense doesn't HDBC support MySQL??

It doesn't have a MySQL backend. However, it does have an ODBC backend which should work fine with MySQL.

This was uploaded to hackage yesterday: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-mysql-0.1 You might like to test it and give feedback to the author. Duncan

On Jan 23, 2009, at 1:23 AM, Duncan Coutts wrote:

On Fri, 2009-01-23 at 08:06 +0000, Sebastian Sylvan wrote:

...

2009/1/23 Galchin, Vasili Hello,

"Real World Haskell" seems to say that the abstraction layer HDBC doesn't support MySQL. If so, in what sense doesn't HDBC support MySQL??

It doesn't have a MySQL backend. However, it does have an ODBC backend which should work fine with MySQL.

This was uploaded to hackage yesterday:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-mysql-0.1

You might like to test it and give feedback to the author.

I would very much appreciate feedback. I'm still working with John Goerzen (who has been extremely helpful) to iron our some details, see [1] for a list of issues that you should be aware of before you start doing anything too serious. thanks! chris [1] http://www.maubi.net/~waterson/hacks/hdbc-mysql.html

On Jan 25, 2009, at 4:25 AM, Yitzchak Gale wrote:

o Transactions - if a connection does not support transactions, dbTransactionSupport should return False, and commit and rollback should raise errors. (SqlError I suppose?) Not warnings.

You probably already know this, but...the problem is that the "connection" doesn't really have anything to do with supporting transactions in MySQL; the storage engine that backs a particular table does. A single connection can interact with tables that are backed by a variety of different storage engines. In fact, you can mix tables from different storage engines in a single *statement*. To strictly implement HDBC's semantics, I could report that a MySQL connection doesn't support transactions, ever. Internally, I'd turn on auto-commit to force each statement to run in its own transaction, always. This is certainly correct, however, it severely limits the utility of the driver IMO. For now, I've opted to do (essentially) what the ODBC driver does with MySQL connections. Namely, I trust the programmer to use the driver correctly, and fail silently if he misuses this privilege. I don't love this, but it seems to be the way MySQL is generally dealt with in other languages. It is possible for me to detect when a ROLLBACK has been issued against a non-transactional table. In this case, I could raise an error; however, doing this would be different behavior than the ODBC driver. (Besides being too late for the programmer to do anything about it!) But perhaps this is preferable?

o Threading - see the section at the bottom of the Haddock page for a nice specification of what the driver needs and does not need to support.

Gah. I don't know how I missed this. Thanks for pointing it out.

Also -

o Non-ASCIIText - OK for now, but MySQL has significant support for Unicode and encodings, so that should be on the to-do list.

Agreed. thanks! chris

Chris Waterson wrote:

...

You probably already know this, but... you can mix tables from different storage engines in a single *statement*.

Oh, no, I thought it was per database. Horrors!

...

...when a ROLLBACK has been issued against a non-transactional table... I could raise an error... perhaps this is preferable?

John Goerzen wrote:

...what happens in the ODBC case depends on what the user puts in odbc.ini... either the full-on error treatment, or the ignoring the problem

It does make sense for this to be configurable. In addition, you might want even more than the current "full-on error" mode: As Chris pointed out, throwing an exception at commit or rollback is a bit late - your data may already be destroyed by then. There should be a "safe" mode that raises an exception any time you try make a change to a non-transactional table, even before commit or rollback. That way, you would be able to write code like this: Start doing A in a new transaction. If any operation tries to make a change in a non-transactional table, roll back A and do B instead. Transactional "safe" mode could still allow reads of non-transactional tables. Is this possible for MySQL and/or ODBC?

If you feel that the HDBC API needs to become more rich, I'm quite happy to entertain suggestions there

Well, this makes a major difference in the meaning of a program. So it does seem that it should be possible at least to detect what is happening, or even control it programatically. In the case of a connection with less than guaranteed full support for transactions, you would want to be able to choose between the two behaviors available in the ODBC driver, or "safe" mode. Right now, the meaning of the dbTransactionSupport flag is ambiguous. Does True mean that full support for transactions is guaranteed? Or only that it might be supported for some tables? If not supported for some table, will the driver revert to irrevocable immediate changes, or raise an exception? Will silently ignore commit and rollback requests, or raise an exception? Even before the API becomes richer in this respect, the documentation should more clearly indicate the meaning of this flag (and drivers should then comply). Thanks, Yitz

...

...

...

...

"Sebastian" == Sebastian Sylvan writes:

Sebastian> It doesn't have a MySQL backend. However, it does have an Sebastian> ODBC backend which should work fine with MySQL. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-mysql Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------