Hi,
Ticket #22343[1] is about a couple of tests failing under Oracle. But it
raises a question that's a little deeper.
The relevant tests do a select-for-update to verify that the "for update"
clause is, indeed, added; and they happen to run in autocommit mode. They fail
because, under Oracle, in autocommit mode, the automatic commit happens
immediately after the command is executed -- and so, trying to fetch the
results fails for being done in a separate transaction.
However, with any backend, select-for-update in autocommit mode makes very
little sense. Even if it doesn't break (as it does on Oracle), it doesn't
really lock anything. So, IMO, executing a query that is a select-for-update
in autocommit mode is probably en error, and one that is likely to cause data-
corruption bugs.
So I'm suggesting we change the behavior of select-for-update queries, to
error out when executed with no transaction. This is a backwards-incompatible
change -- for some projects, app they have used happily before will suddenly
break. These projects should probably be thankful -- they were running with a
subtle bug that is now exposed -- but still.
Unless there are convincing objections to this, I'd even like to backport this
change, at least to 1.6, because of the potential data-corruption bugs.
Your opinions are welcome.
Thanks,
Shai.
[1] https://code.djangoproject.com/ticket/22343
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/201403271620.23959.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.
