Cursor row_cast_map and schema changes
"Simon Cross" <[email protected]>
| Newsgroups | gmane.comp.python.db.pysqlite.user |
|---|---|
| Message-ID | <[email protected]> |
I've come across what I think is a bug in how type dection interacts
with schema changes.
What happens is that after dropping and then recreating a table with a
different schema the converts used are briefly still the old
converters. What alerted me to the problem is that the default
timestamp converter throws an error if it can't split the value it
gets back (which happens if the column has been changed to an integer,
for example). What makes thing really weird (and makes me wonder if I
actually understand what's going on) is that the old converters are
present after I've successfully executed an INSERT statement.
Having looked around the pysqlite code a bit, I think the problem
might be that the call to build_row_cast_map might doesn't happen
again if sqlite returns a schema change error and the statement is
re-tried. I thought maybe build_row_cast_map might be moved until
after the statement has been executed?
I've created a test (included below) which illustrates the problem and
included it below. If there is a way to work around this (or I'm using
pysqlite incorrectly) I'd appreciate hearing about it.
Schiavo
Simon
---------
import sqlite3
import datetime
def main():
conn = sqlite3.connect("test.db",detect_types=sqlite3.PARSE_DECLTYPES)
coltypes = [ ('timestamp', datetime.datetime.now()),
('integer', 5),
]
try:
conn.execute("DROP TABLE foo")
except:
pass
try:
for i in range(10):
for coltype, data in coltypes:
conn.execute("CREATE TABLE foo (col1 %s)" % coltype)
conn.execute("INSERT INTO foo (col1) VALUES ('%s')" % data)
cursor = conn.execute("SELECT col1 FROM foo")
cursor.close()
conn.execute("DROP TABLE foo")
finally:
conn.close()
print "Failed with column type '%s' and data '%s'." % (coltype, data)
if __name__ == "__main__":
main()
---------