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