#16352: Simultaneous user work with django.contrib.admin
-------------------------------------+-------------------------------------
Reporter: pelid80@… | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: contrib.admin
Version: 1.3 | Severity: Normal
Resolution: | Keywords:
Triage Stage: Design | Has patch: 0
decision needed | Needs tests: 0
Needs documentation: 0 | Easy pickings: 0
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* needs_docs: => 0
* stage: Unreviewed => Design decision needed
* needs_tests: => 0
* needs_better_patch: => 0
Comment:
To the best of my knowledge, the admin doesn't implement any kind of
locking or collision detection. Such race conditions trigger a 500.
The problem itself can't be solved: anything could alter the database
outside of Django's control. Even if only Django touches the database,
objects can be deleted by any code, and the admin has no way of knowing
what happens.
Django could try to handle this kind of error more gracefully, but I'm not
sure we want to do that. A 500 page usually says "please retry later"; the
user will press "Back", "Refresh", see that a row has disappeared, and
figure out what happened. It's fairly easy to implement optimistic locking
if you need it.
Related discussion on SO: http://stackoverflow.com/questions/320096
/django-how-can-i-protect-against-concurrent-modification-of-data-base-
entries
--
Ticket URL: <https://code.djangoproject.com/ticket/16352#comment:1>
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
