[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

[Gian-Carlo Pascutto]

Gian-Carlo Pascutto added the comment:

>Then we wait for someone that really knows why the change was done in the 
>first place.

Python 2.7 had a regression compared to 2.6 where a SELECT after a COMMIT would 
silently return the wrong data:

http://bugs.python.org/issue23129
http://bugs.python.org/issue10513

Neither exiting with a locked error nor producing the wrong data are 
particularly appealing results. Did 2.6 pass those sets that caused the 
attempted fix to get backed out?

--
nosy: +Gian-Carlo Pascutto

___
Python tracker 
<http://bugs.python.org/issue29006>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results

[Gian-Carlo Pascutto]

Gian-Carlo Pascutto added the comment:

I've ran into this as well, when a program that was running correctly with 
PostgreSQL turned out to produce garbage with SQLite. Code to reproduce roughly 
looks like this:

sel_cursor = conn.cursor()
sel_cursor.execute("SELECT prim_key_id FROM "
   "somedb ORDER BY start_time ASC")
add_cursor = conn.cursor()
prim_keys = set()
row = sel_cursor.fetchone()
while row:
seq = row[0]
if seq in prim_keys:
raise RuntimeError
prim_keys.add(seq)
add_cursor.execute("INSERT INTO someotherdb "
   "VALUES (?)",
   seq)
conn.commit()
row = sel_cursor.fetchone()
conn.commit()

This will raise a RuntimeError because the SELECT will return the same primary 
key value twice - something that's obviously impossible.

This exact bug has been filed once more already, and it seems to be an actual 
regression in Python 2.7:
http://bugs.python.org/issue10513

Looking at the code there, I agree with the analysis in this message: 
http://bugs.python.org/issue10513#msg150162

Either the pysqlite_do_all_statements should set reset_cursors=1 to warn the 
user that the cursor has been reset, or it shouldn't reset them to begin with 
(as Python <2.7 used to do).

I don't think there's any argument this isn't a (bad) bug: Python <2.7 works 
correctly and later versions silently corrupt data.

--
nosy: +Gian-Carlo Pascutto

___
Python tracker 
<http://bugs.python.org/issue23129>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10513] sqlite3.InterfaceError after commit

[Gian-Carlo Pascutto]

Gian-Carlo Pascutto added the comment:

I believe http://bugs.python.org/issue23129 is a dupe of this.

The patch here has been in "patch review" for 9 months. That seems fairly long 
for something that's a regression that potentially silently produces the wrong 
data.

------
nosy: +Gian-Carlo Pascutto

___
Python tracker 
<http://bugs.python.org/issue10513>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com