Python – Why does windows give an sqlite3.OperationalError and linux does not

linuxpythonsqlitewindows

The problem

I've got a programm that uses storm 0.14 and it gives me this error on windows:

sqlite3.OperationError: database table is locked

The thing is, under linux it works correctly.

I've got the impression that it happens only after a certain amount of changes have been done, as it happens in some code, that copies a lot of objects.

Turning on the debug mode gives me this on windows:

83 EXECUTE: 'UPDATE regularorder_product SET discount=? WHERE regularorder_product.order_id = ? AND regularorder_product.product_id = ?', (Decimal("25.00"), 788, 274)
84 DONE
85 EXECUTE: 'UPDATE repeated_orders SET nextDate=? WHERE repeated_orders.id = ?', (datetime.date(2009, 3, 31), 189)
86 ERROR: database table is locked

On linux:

83 EXECUTE: 'UPDATE regularorder_product SET discount=? WHERE regularorder_product.order_id = ? AND regularorder_product.product_id = ?', (Decimal("25.00"), 789, 274)
84 DONE
85 EXECUTE: 'UPDATE repeated_orders SET nextDate=? WHERE repeated_orders.id = ?', (datetime.date(2009, 3, 31), 189)
86 DONE

System info

Windows

Windows XP SP 3
Python 2.5.4
NTFS partition

Linux

Ubuntu 8.10
Python 2.5.2
ext3 partition

Some code

def createRegularOrderCopy(self):
    newOrder = RegularOrder()
    newOrder.date = self.nextDate
    # the exception is thrown on the next line,
    # while calling self.products.__iter__
    # this happens when this function is invoked the second time
    for product in self.products:
        newOrder.customer = self.customer
        newOrder.products.add(product)
        return newOrder

orders = getRepeatedOrders(date)
week = timedelta(days=7)

for order in orders:
    newOrder = order.createRegularOrderCopy()
    store.add(newOrder)
    order.nextDate = date + week

The question

Is there anything about sqlite3/python that differs between windows and linux? What could be the reason for this bug and how can I fix it?

Another observation

When adding a COMMIT at the place where the error happens, this error is thrown instead: sqlite3.OperationalError: cannot commit transaction - SQL statements in progress

Answers to answers

I'm not using multiple threads / processes, therefore concurrency shouldn't be a problem and also I've got only one Store object.

Best Solution

The "database table is locked" error is often a generic/default error in SQLite, so narrowing down your problem is not obvious.

Are you able to execute any SQL queries? I would start there, and get some basic SELECT statements working. It could just be a permissions issue.

Related Solutions

Python – What does ** (double star/asterisk) and * (star/asterisk) do for parameters

The *args and **kwargs is a common idiom to allow arbitrary number of arguments to functions as described in the section more on defining functions in the Python documentation.

The *args will give you all function parameters as a tuple:

def foo(*args):
    for a in args:
        print(a)        

foo(1)
# 1

foo(1,2,3)
# 1
# 2
# 3

The **kwargs will give you all keyword arguments except for those corresponding to a formal parameter as a dictionary.

def bar(**kwargs):
    for a in kwargs:
        print(a, kwargs[a])  

bar(name='one', age=27)
# name one
# age 27

Both idioms can be mixed with normal arguments to allow a set of fixed and some variable arguments:

def foo(kind, *args, **kwargs):
   pass

It is also possible to use this the other way around:

def foo(a, b, c):
    print(a, b, c)

obj = {'b':10, 'c':'lee'}

foo(100,**obj)
# 100 10 lee

Another usage of the *l idiom is to unpack argument lists when calling a function.

def foo(bar, lee):
    print(bar, lee)

l = [1,2]

foo(*l)
# 1 2

In Python 3 it is possible to use *l on the left side of an assignment (Extended Iterable Unpacking), though it gives a list instead of a tuple in this context:

first, *rest = [1,2,3,4]
first, *l, last = [1,2,3,4]

Also Python 3 adds new semantic (refer PEP 3102):

def func(arg1, arg2, arg3, *, kwarg1, kwarg2):
    pass

Such function accepts only 3 positional arguments, and everything after * can only be passed as keyword arguments.

Note:

A Python dict, semantically used for keyword argument passing, are arbitrarily ordered. However, in Python 3.6, keyword arguments are guaranteed to remember insertion order.
"The order of elements in **kwargs now corresponds to the order in which keyword arguments were passed to the function." - What’s New In Python 3.6
In fact, all dicts in CPython 3.6 will remember insertion order as an implementation detail, this becomes standard in Python 3.7.

Python – a mixin, and why are they useful

A mixin is a special kind of multiple inheritance. There are two main situations where mixins are used:

You want to provide a lot of optional features for a class.
You want to use one particular feature in a lot of different classes.

For an example of number one, consider werkzeug's request and response system. I can make a plain old request object by saying:

from werkzeug import BaseRequest

class Request(BaseRequest):
    pass

If I want to add accept header support, I would make that

from werkzeug import BaseRequest, AcceptMixin

class Request(AcceptMixin, BaseRequest):
    pass

If I wanted to make a request object that supports accept headers, etags, authentication, and user agent support, I could do this:

from werkzeug import BaseRequest, AcceptMixin, ETagRequestMixin, UserAgentMixin, AuthenticationMixin

class Request(AcceptMixin, ETagRequestMixin, UserAgentMixin, AuthenticationMixin, BaseRequest):
    pass

The difference is subtle, but in the above examples, the mixin classes weren't made to stand on their own. In more traditional multiple inheritance, the AuthenticationMixin (for example) would probably be something more like Authenticator. That is, the class would probably be designed to stand on its own.