Does MySQLdb rollback on control-C? Maybe not.
nagle at animats.com
Fri Sep 3 06:22:12 CEST 2010
I would expect MySQLdb to rollback on a control-C, but it doesn't
seem to have done so. I have a program which does a thousand or
so INSERT operations in one transaction on an InnoDB table.
I kill it with a control-C on Windows, and it aborts. But
it looks like some of the INSERT operations took place. Here's
the abort, from the middle of an INSERT operation.
Filing index item already in database under another date:
Traceback (most recent call last):
File "C:\projects\sitetruth\edgar\edgarfilingindex.py", line 93, in
cursor.execute(sql, values) # do the insert
File "C:\python26\lib\site-packages\MySQLdb\cursors.py", line 166, in
self.errorhandler(self, exc, value)
File "C:\python26\lib\site-packages\MySQLdb\connections.py", line 35,
raise errorclass, errorvalue
Terminate batch job (Y/N)? y
Checking with the manual MySQL client, looking at the table
before and after the run, the table did change when the program ran.
The INSERT looks like this:
INSERT INTO edgarfilingindex
(cik, company_name, form_type,
date_filed, file_name, date_indexed, confidence)
SHOW CREATE TABLE returns this:
CREATE TABLE `edgarfilingindex` (
) ENGINE=InnoDB DEFAULT CHARSET=utf8
so it's definitely an InnoDB table.
I have print statements at all commit calls, and there don't seem to
be any unwanted commits happening. I'm not doing anything that
forces a commit, like RENAME or ALTER or CREATE; it's just
simple INSERT operations. I'm not doing an explicit START
TRANSACTION, but I shouldn't have to.
I put a SHOW VARIABLES LIKE "autocommit" in the program, and
it comes back with ("autocommit", "OFF"). So that's not the problem.
I even did an explicit START TRANSACTION at the beginning of the
update, and it doesn't help.
Something is broken.
Python 2.6, MySQLdb 1.2.2-py2.6, MySQL 5.1.47-com, Windows 7.
More information about the Python-list