sqlite3 broken post rev 329

[gch@…]

Changes to function_get_list in meta.py in [329] seem to have broken support for sqlite3. Loading the barebones admin site in [328] works fine. If I do the same with [329], I get the following stack trace posted here: ​http://pastebin.com/323094

[Adrian Holovaty]

Jeez, is the Python SQLite module so broken that it doesn't know how to handle cursor.fetchmany()?

I don't have immediate access to SQLite. Could you try running polls.get_iterator() using SQLite, in the version that *does* work for you ([328])? If my hunch is correct, that won't work, either.

[rmunn@…]

The cursor.fetchmany() function in pysqlite2 seems to work fine for me:

Python 2.4.1 (#2, Jul 21 2005, 15:58:35) 
[GCC 4.0.2 20050720 (prerelease) (Debian 4.0.1-2ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pysqlite2 import dbapi2 as sqlite
>>> conn = sqlite.connect('/home/rmunn/projects/learndjango/django-data.db')
>>> curs = conn.cursor()
>>> curs.execute('select * from foo')
>>> curs.fetchmany(2)
[(1, u'one'), (2, u'two')]
>>> curs.fetchmany(2)
[(3, u'three'), (4, u'four')]
>>> curs.fetchmany(2)
[]

Running the polls application from the tutorial also works for me, both calling polls.get_list() and polls.get_iterator(), all on sqlite3. I don't think cursor.fetchmany() is the culprit here.

In case it makes a difference, I'm running sqlite3 version 3.2.1 and revision 332 of Django.

[gch@…]

I was able to do the same python code as rmunn posted. If I have a 4-item table, then the first call to "fetchmany(2)" returns 2 items, as does the second. The third call returns the empty list. If you make a 4th call, however, I get the same error, which suggests that our problem may be from erroneous bounds checking.

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
pysqlite2.dbapi2.ProgrammingError: no compiled statement - you need to execute() before you can fetch data

Adrian, I am able to run polls.get_iterator() just fine on both [328] and [329] (both return a pointer to the iterator) but not polls.get_list(), which only works with [328].

>>> polls.get_iterator()
<generator object at 0xb7becb4c>

[Adrian Holovaty]

That's interesting...

gch, which versions of SQLite 3 and the Python bindings are you using?

[gch]

dev-db/sqlite-3.2.1-r3
dev-python/pysqlite-2.0.2

[rmunn@…]

I think the bug is in pysqlite 2.0.2 - see ​http://initd.org/tracker/pysqlite/wiki/2.0.3_Changelog for a list of changes, one of which fixes a bug which sound suspiciously like this one.

I believe the answer is to upgrade to pysqlite 2.0.3.

[rmunn@…]

Oh, and when I ran the code above at the interactive prompt, I actually called cursor.fetchmany(2) a fourth time, which I left out of the cut&paste because I hadn't thought it was relevant. Silly me... :-) It succeeded, returning an empty list just like the third call had done.

I'm 99.8% confident now that this bug will go away if you update to pysqlite 2.0.3.

[gch]

Well, that 99.8% won out! I tried with pysqlite 2.0.3, and the problem is gone. Thanks a lot guys! I'll let you all mark this as resolved.

[Adrian Holovaty]

Great. I'm glad this got worked out. I've updated the docs in [335] to mention pysqlite 2.0.3 explicitly.