Python – cursor.rowcount always -1 in sqlite3 in python3k

databasepythonsqlite

I am trying to get the rowcount of a sqlite3 cursor in my Python3k program, but I am puzzled, as the rowcount is always -1, despite what Python3 docs say (actually it is contradictory, it should be None). Even after fetching all the rows, rowcount stays at -1. Is it a sqlite3 bug? I have already checked if there are rows in the table.

I can get around this checking if a fetchone() returns something different than None, but I thought this issue would be nice to discuss.

Thanks.

Best Solution

From the documentation:

As required by the Python DB API Spec, the rowcount attribute “is -1 in case no executeXX() has been performed on the cursor or the rowcount of the last operation is not determinable by the interface”.

This includes SELECT statements because we cannot determine the number of rows a query produced until all rows were fetched.

That means all SELECT statements won't have a rowcount. The behaviour you're observing is documented.

EDIT: Documentation doesn't say anywhere that rowcount will be updated after you do a fetchall() so it is just wrong to assume that.

Related Solutions

Python – Should you always favor xrange() over range()

For performance, especially when you're iterating over a large range, xrange() is usually better. However, there are still a few cases why you might prefer range():

In python 3, range() does what xrange() used to do and xrange() does not exist. If you want to write code that will run on both Python 2 and Python 3, you can't use xrange().
range() can actually be faster in some cases - eg. if iterating over the same sequence multiple times. xrange() has to reconstruct the integer object every time, but range() will have real integer objects. (It will always perform worse in terms of memory however)
xrange() isn't usable in all cases where a real list is needed. For instance, it doesn't support slices, or any list methods.

[Edit] There are a couple of posts mentioning how range() will be upgraded by the 2to3 tool. For the record, here's the output of running the tool on some sample usages of range() and xrange()

RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
--- range_test.py (original)
+++ range_test.py (refactored)
@@ -1,7 +1,7 @@

 for x in range(20):
-    a=range(20)
+    a=list(range(20))
     b=list(range(20))
     c=[x for x in range(20)]
     d=(x for x in range(20))
-    e=xrange(20)
+    e=range(20)

As you can see, when used in a for loop or comprehension, or where already wrapped with list(), range is left unchanged.

Python – Why is init() always called after new()

Use __new__ when you need to control the creation of a new instance.

Use __init__ when you need to control initialization of a new instance.

__new__ is the first step of instance creation. It's called first, and is responsible for returning a new instance of your class.

In contrast, __init__ doesn't return anything; it's only responsible for initializing the instance after it's been created.

In general, you shouldn't need to override __new__ unless you're subclassing an immutable type like str, int, unicode or tuple.

From April 2008 post: When to use __new__ vs. __init__? on mail.python.org.

You should consider that what you are trying to do is usually done with a Factory and that's the best way to do it. Using __new__ is not a good clean solution so please consider the usage of a factory. Here's a good example: ActiveState Fᴀᴄᴛᴏʀʏ ᴘᴀᴛᴛᴇʀɴ Recipe.

Best Solution

Related Solutions

Python – Should you always favor xrange() over range()

Python – Why is __init__() always called after __new__()

Related Question

Python – Why is init() always called after new()