id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
10450	Savepoint should not assume an opened connection	Jeremy Dunck	nobody	"Using django transaction.savepoint() without having previously used a cursor fails if the backend actually supports savepoints.

e.g. Using postgres:
{{{
Python 2.5.2 (r252:60911, Mar 18 2008, 15:01:36) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type ""help"", ""copyright"", ""credits"" or ""license"" for more information.
>>> from django.db import transaction
>>> transaction.savepoint()
Traceback (most recent call last):
  File ""<stdin>"", line 1, in <module>
  File ""/Users/jeremydunck/work/django/g-django/django/db/transaction.py"", line 188, in savepoint
    connection._savepoint(sid)
  File ""/Users/jeremydunck/work/django/g-django/django/db/backends/__init__.py"", line 43, in _savepoint
    self.connection.cursor().execute(self.ops.savepoint_create_sql(sid))
AttributeError: 'NoneType' object has no attribute 'cursor'
}}}

It seems this problem has existed since savepoints were introduced, but I found it by trying to use the cached_db sessions backend.

In any case, the problem is that the savepoint family of methods on BaseDatabaseWrapper make the assumption that self.connection has been initiailized-- this is not a safe assumption.  self.connection is initialized the first time BaseDatabaseWrapper.cursor is called, and that may not have happened before BaseDatabaseWrapper._savepoint*. 

In all cases, ._savepoint* goes on to use connection.cursor, so I think it's safe to just use self.cursor() directly rather than self.connection.cursor().

Patch attached.

Unfortunately, I'm not sure how to make a test for this, because django's test suite itself uses django.db.connection.

At least it is easy to reproduce.  :-)"		closed	Database layer (models, ORM)	1.0		fixed			Accepted	1	0	0	0	0	0