#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-------------------------------------+-------------------------------------
Reporter: | Owner:
sebastian_noack | Status: new
Type: | Component: Database layer
Cleanup/optimization | (models, ORM)
Milestone: 1.4 | Severity: Normal
Version: SVN | Keywords: mysql transaction
Resolution: | isolation
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
There is one good reason why .save() should do a select first. It is very
explicitly documented that this is what save() does [1]. I wonder if that
is really a backwards compatibility requirement even if it is documented
that explicitly.
For the matter if databases should be allowed to specify the isolation
level, I don't understand the reason for not allowing it. The reasoning
goes something like this:
Django is designed to work in READ COMMITTED mode. You can not change this
because Django might not work properly in other isolation levels. However,
for backwards compatibility reasons MySQL works in REPEATABLE READ mode
and because of this it does not work correctly in some cases. We do not
allow you to change this because Django might not work properly in other
than READ COMMITTED mode. Hmmm...
So at least MySQL users should be allowed to set the isolation level to
READ COMMITTED, but IMHO it would be good to allow isolation level
settings for all databases.
One choice here would be to allow users to specify other isolation levels
and document that Django is designed to work best in READ COMMITTED mode.
Use other level at your own risk. The default for new projects is READ
COMMITTED, but for backwards compatibility reasons REPEATABLE READ is used
for MySQL if not otherwise specified in the settings.py file. The downside
is that for new projects, the ISOLATION_LEVEL setting must be in the
settings.py file.
Reasons for other databases are that some databases really work much
better in other isolation levels (non MVCC databases for example), and
that you might be using a legacy database that is designed to work in
other isolation levels. Also, PostgreSQL 9.1 and true serializable
transactions... :)
[1] https://docs.djangoproject.com/en/dev/ref/models/instances/#how-
django-knows-to-update-vs-insert
--
Ticket URL: <https://code.djangoproject.com/ticket/13906#comment:27>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
