Attention Oracle developers: savepoint implementation

5 views
Skip to first unread message

Malcolm Tredinnick

unread,
Aug 12, 2008, 1:40:44 AM8/12/08
to django-d...@googlegroups.com
In [8314], I've added some savepoint support for the PostgreSQL
backends. This isn't needed on SQLite or MySQL, but in the PostgreSQL
backends the same transaction is visible to all cursors and any
integrity error requires a rollback before anything else can be done.
The implementation is such that the API can be used generally and it
just results in a no-op for most backends.

What I am not sure about is whether anything needs to be implemented for
Oracle or not. Right now, it does nothing there. The test for whether
it's needed is probably just to see if the current versions of the
force_insert_update and one_to_one tests run without an error, since
I've removed the forced connection closing there in favour of
savepoints.

Hopefully it's clear enough from the change in [8314] what's required if
something is needed. If not, or if we need some more knobs there, please
sing out.

Regards,
Malcolm


Matt Boersma

unread,
Aug 12, 2008, 11:04:57 AM8/12/08
to Django developers
Thanks for the heads up, Malcolm. Ian Kelly and I will take a look at
it. I notice the test suite is failing entirely as of yesterday for
Oracle:
Python 2.5 / oracle: TypeError: _test_database_name() takes exactly 1
argument (2 given), 6 seconds elapsed
I'm guessing that's related, so we'll fix that.

Matt

On Aug 11, 11:40 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

Leo Soto M.

unread,
Aug 12, 2008, 11:13:23 AM8/12/08
to django-d...@googlegroups.com
On Tue, Aug 12, 2008 at 11:04 AM, Matt Boersma <ogg...@gmail.com> wrote:
>
> Thanks for the heads up, Malcolm. Ian Kelly and I will take a look at
> it. I notice the test suite is failing entirely as of yesterday for
> Oracle:
> Python 2.5 / oracle: TypeError: _test_database_name() takes exactly 1
> argument (2 given), 6 seconds elapsed
> I'm guessing that's related, so we'll fix that.

I suspect that the _test_database_name() problem was caused by the
refactor done on #5461[1].

BTW, if you can give me a hand with
<http://groups.google.com/group/django-developers/browse_thread/thread/e2fde44dac7391c0>,
I can provide a buildbot-like system for django/oracle testing.

[1] http://code.djangoproject.com/ticket/5461
--
Leo Soto M.
http://blog.leosoto.com

Malcolm Tredinnick

unread,
Aug 12, 2008, 11:17:52 AM8/12/08
to django-d...@googlegroups.com

On Tue, 2008-08-12 at 08:04 -0700, Matt Boersma wrote:
> Thanks for the heads up, Malcolm. Ian Kelly and I will take a look at
> it.

In case it helps the analysis: the only reason this is really required
at all is because we set up the PostgreSQL connection to make the same
transaction visible to all cursors and we use a new cursor for every SQL
statement. This doesn't seem to be the case for MySQL, where we don't
have to do special configuration of the connection and creating a
savepoint in one cursor (with InnoDB) doesn't affect another cursor.

The DB-API is a little odd in that area: transaction starts are done
through a cursor and commit/rollbacks are done through the connection
objects. Savepoints are done through a cursor, again. I kind of
understand why, but it twisted my brain a bit when trying to work out if
MySQL needed this support, too.

So, basically, if the same transaction is visible to each cursor in
Oracle or if one cursor's behaviour affects another w.r.t savepoints,
you probably need this. Otherwise, you should be able to punt.


> I notice the test suite is failing entirely as of yesterday for
> Oracle:
> Python 2.5 / oracle: TypeError: _test_database_name() takes exactly 1
> argument (2 given), 6 seconds elapsed

Look on the bright side. The Oracle tests run so much faster now. :-)

> I'm guessing that's related, so we'll fix that.

I didn't touch _test_database_name(), at least not directly. Remember
(or realise, if you didn't notice) that there's been a lot of other
changes in the database backends over the last 24 - 48 hours. Russell's
landed a big reorganisation in [8296] that will probably be relevant.

Cheers,
Malcolm

Reply all
Reply to author
Forward
0 new messages