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
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
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