Oracle savepoints

[Richard Davies]

Calling any Oracle developer (Matt Boersma?, Ian Kelly?),

I see that the Oracle backend has had savepoint support since [10022]
in March.

I'd like to understand whether this was done:
a) simply to add the feature (which is good!)
b) "by necessity" to be able to perform savepoint rollback when a
transaction gets broken by IntegrityErrors

Savepoints were first implemented in Postgresql with [8314] last
August, and were implemented for reason (b). Once a Postgresql
transaction experiences an IntegrityError, it refuses all further
commands with "current transaction is aborted, queries ignored until
end of transaction block" until it has been rolled back to a prior
savepoint (see http://groups.google.com/group/django-developers/browse_thread/thread/c87cf2d97478c068/
, http://docs.djangoproject.com/en/dev/topics/db/transactions/#handling-exceptions-within-postgresql-transactions)

Are savepoints needed for this reason (b) in Oracle too, or are they
simply there as a feature for users?

i.e. does an Oracle transaction continue to function without savepoint
rollback after an IntegrityError?

Thanks,

Richard.

[Richard Davies]

My question is effectively the same as asking if the test suite passed
on Oracle between [8314] in August 2008 and [10022] in March 2009.

I assume that it must have passed during those six months (Django 1.0
was [8961] in September 2008!), which would imply that Oracle
savepoints were implemented for reason (a) to add the feature rather
than reason (b) by necessity.

But please can someone confirm?

Thanks,

Richard.

[Matt Boersma]

On Sat, May 16, 2009 at 1:42 PM, Richard Davies
<richard...@elastichosts.com> wrote:
>
> My question is effectively the same as asking if the test suite passed
> on Oracle between [8314] in August 2008 and [10022] in March 2009.
>
> I assume that it must have passed during those six months (Django 1.0
> was [8961] in September 2008!), which would imply that Oracle
> savepoints were implemented for reason (a) to add the feature rather
> than reason (b) by necessity.

I think Malcolm implemented this in the Oracle backend rather than Ian
K. or myself. The test suite has been passing all but a few cases on
Oracle in general since before the 1.0 release.

So I'd say the answer is a).

[Richard Davies]

Matt Boersma wrote:
> I think Malcolm implemented this in the Oracle backend rather than Ian
> K. or myself.

It was Ian Kelly, I think in [10022].

> So I'd say the answer is a).

If that's right, then we have an inefficiency on Oracle at present -
the uses_savepoints flag is used both to signal that savepoints are
implemented (see BaseDatabaseWrapper._savepoint*() in django/db/
backends/__init__.py), and to signal that they are needed to wrap code
which may throw IntegrityErrors (as per reason b; see
QuerySet.get_or_create() in django/db/models/query.py).

We should probably be splitting these two meanings, so Postgresql
would have:

can_savepoint = True
needs_savepoint_after_exception = True

Whereas Oracle would have:

can_savepoint = True
needs_savepoint_after_exception = False

I'll open a ticket to remember this once Ian, Malcolm or another also
confirms.

Cheers,

Richard.

[Ian Kelly]

Yes, it was reason a). Transactions aren't automatically invalidated
after an IntegrityError, as far as I was able to determine.

Regards,
Ian

[Richard Davies]

On May 18, 5:12 pm, Ian Kelly wrote:
> Yes, it was reason a).  Transactions aren't automatically invalidated
> after an IntegrityError, as far as I was able to determine.

Thanks Ian. Ticket #11156 records the current inefficiency on Oracle.

Cheers,

Richard.