Concurrency dans django admin Modifier la

Question

Mon modèle:

class Order(models.Model): 
    property_a = models.CharField() 
    property_b = models.CharField() 
    property_c = models.CharField() 

De nombreux utilisateurs auront accès à un enregistrement donné dans un court laps de temps par page changement d'administration, donc j'ai des problèmes de concurrence:

utilisateur 1 et 2 ouvrez la page de modification en même temps. Supposons que toutes les valeurs sont vides lors du chargement de la page. L'utilisateur 1 définit property_a sur "a", et property_b sur "b", puis enregistre. Une seconde plus tard, si l'utilisateur 2 modifie la propriété b et c puis l'enregistre, il écrasera toutes les valeurs de l'utilisateur 1. Dans ce cas, property_a retournera à vide et b et c sera tout ce que l'utilisateur 2 a ajouté.

J'ai besoin de recommandations sur la façon de gérer cela. Si je dois avoir un champ de version dans le modèle, comment puis-je le transmettre à l'administrateur, où puis-je faire la vérification pour informer élégamment l'utilisateur que ses modifications ne peuvent pas être enregistrées parce qu'un autre utilisateur a modifié l'enregistrement? Existe-t-il un moyen plus transparent que de simplement renvoyer une erreur à l'utilisateur?

Answer 1

La solution standard consiste à empêcher vos utilisateurs de partager un seul enregistrement. Il n'est pas du tout clair pourquoi tant d'utilisateurs jouent avec la même instance Order. Considérons que Order est probablement un objet composite et vous en avez trop mis dans un seul modèle. C'est la première - et la meilleure - solution.

Si (pour des raisons inexplicables) vous ne décomposerez pas cela, alors vous devez créer une transaction de mise à jour en deux parties.

1. Requérir les données. Comparer avec la requête d'origine comme fait pour la session de cet utilisateur.

2. Si les données ne correspondent pas à la requête d'origine, quelqu'un d'autre l'a modifiée. Les modifications de l'utilisateur sont invalidées, annulées, effacées et l'utilisateur voit une nouvelle requête.

3. Si les données correspondent, vous pouvez essayer de valider la modification.

L'algorithme ci-dessus a une condition de concurrence, qui est généralement résolue via un SQL de bas niveau. Notez qu'il invalide le travail d'un utilisateur, le rendant irritant au maximum.

C'est pourquoi votre premier choix est de décomposer vos modèles pour éliminer la concurrence.

---

mon modèle a un champ de notes diverses

Ceci est une mauvaise conception. (a) La concurrence est ruinée par des collisions sur ce champ. (b) Il n'y a pas de journal ou d'historique des commentaires. Le point (b) signifie qu'un utilisateur mal intentionné peut corrompre ces données de façon malveillante. Si vous conservez des notes et des commentaires sous forme de journal, vous pouvez en principe limiter les utilisateurs à modifier uniquement leurs propres commentaires. [Dans la plupart des bases de données contenant des "notes diverses", le champ est devenu une responsabilité coûteuse et difficile à maintenir, remplie de données importantes mais impossibles à analyser. Les notes diverses sont celles où les utilisateurs inventent leurs propres processus en dehors du logiciel d'application.]

Les "notes diverses" doivent être traitées comme un journal, avec un nombre illimité de notes - horodatées - identifiées par l'utilisateur - ajouté à l'ordre.

Si vous partitionnez simplement la conception pour placer des notes dans un tableau distinct, vous résolvez vos problèmes de concurrence.