Comment les conflits d'écriture sont-ils évités dans l'administration de Django?

Question

Supposons que deux (ou plus) administrateurs de Django ont lu un enregistrement de base de données, puis l'ont modifié et enregistré. Il n'y a pas de problème de base de données, mais certains administrateurs vont être surpris que l'enregistrement qu'ils ont écrit ait été écrasé.

Cette question a-t-elle déjà été abordée? Une solution consisterait à avoir une "modification en cours" explicite. bouton qui définit un drapeau dans l'enregistrement. Si un autre administrateur lit le même enregistrement, puis clique sur le bouton "Modification en cours". il sera averti qu'une précédente édition est en cours. Ou un champ pourrait être ajouté à l'enregistrement qui est incrémenté lorsqu'un enregistrement est sauvegardé. Si le champ est différent de celui où l'enregistrement a été lu, l'administrateur est averti qu'il a été modifié par quelqu'un d'autre depuis qu'il l'a lu.

Existe-t-il une méthode de traitement django native?

Answer 1

L’administrateur Django n’implémente aucune protection contre les conflits d’écriture. Il ne serait pas difficile de l'ajouter vous-même. Personnellement, je prendrais le champ "numéro de version" " approche.

Answer 2

En règle générale, vous souhaitez consulter les fonctionnalités d'isolation de transaction de votre base de données, car c'est la raison pour laquelle elles ont été créées.

Si vous préférez ne pas le faire, il existe différents modèles pour le faire au niveau de la couche d'application, mais il n'y a pas de moyen canonique de le faire - certaines personnes définissent une sorte de "dernier accès". horodatage et refusent d'autoriser l'édition dans un délai déterminé, les autres numéros de version étant définis, etc., etc.