J'ai implente, piur couvrir ce genre de probleme (enfin pour mon cas), une notion de "lock" logique en integrant un champ locked_id dans le record. En rgos, quand un utilisateur veut prendre un record en edit : - verification que le chamo locked_id = 0 - si ok, je mets le user_id dans ce champ et save le lockd_id avant de renvoyer l'ecran d'edit - quand l'utilsateur sauve ses donnees je remets le locked_id = 0 - quand un utlisateur se delogge, je remets tous les lock eventuels a 0 -une function d'admin me permet de remettre les lock a 0 - quand un utuilisateur veut editer, si un lock est presenet (qui de vient pas du meme utilisateur), j'affiche un message..
C'est simpliste mais cela a l'avantage de ne pas laisser l'utilisateur remplir l'ecran s'il ne peut pas sauver apres. On Jun 9, 11:48 am, Marc MENDEZ <[EMAIL PROTECTED]> wrote: > Neveldo a écrit :> Bonjour, > > > D'après vos explications : les données seront modifiées une première > > fois, puis une seconde. La première modification sera enregistrée dans > > la base de données, puis la seconde modification viendra écraser la > > première. Ce sera donc la dernière modification qui sera prise en > > compte. > > Attention : dans l'exemple que je donne, il y a la notion de temps. > Relisez mon exemple. Je reprécise le cas échéant. > > J'affiche des données D à un instant T sur un écran. L'utilisateur les > modifie à l'écran. Puis il décide de les enregistrer. SAUF qu'entre > temps, un autre utilisateur à lu les mêmes données D, les a modifié et > enregistré plus rapidement que le premier utilisateur. > Deux problèmes se posent : > - les modifications du premier utilisateurs écrasent celle du deuxième, > donc perte des informations. > - dans un second temps, on peut aussi considérer que les modifications > faites par le premier utilisateur (celle qui finalement seront > conservées, car envoyées en dernier à la base de données), ne sont pas > justes, car elles se basent sur des informations D valables à l'instant > T. Or, le deuxième utilisateur a voulu les modifier, donc ce qui veut > dire que ces informations D ne sont plus d'actualités... mais hélas, > elle sont écrasées.... > Pour résumé, le dernier qui a parlé à "raison" ! > > Le problème est de s'assurer qu'entre le moment où les données sont lues > pour être affichées et le moment où on renverra ces données modifiées, > on parle des mêmes données.Imaginez même que le deuxième utilisateur ait > non pas modifié, mais supprimé les données D ! Quel sens donner alors > aux modifications du premier utilisateur ?? > Le problème vient bien évidemment du fait qu'on ne peut pas poser de > verrou sur les données (et encore heureux avec un application sous *AMP !). > Mais l'accès concurrents à des données se posent toujours dès qu'on est > en multiutilisateurs. > > Je me demandais alors si un framework comme CakePHP incluait un système > automatique de gestion des accès concurrents. Les solutions, j'en > connais, mais j'aurais pensé trouver un truc tout fait : > Exemple, un colonne lastupdate, lue en même temps que l'enregistrement, > et dont la valeur est comparé au moment de l'update : si identique, on > valide et on le met à jour, sinon, erreur. > > Existe-t-il donc qq chose d'automatique ? > > > Ceci dit, vous pouvez quand même protéger ce genre d'événement. Pour > > cela, vous pouvez par exemple ajouter un champ "in_edition" à la table > > concernée. Lorsqu'une personne se rend sur le formulaire d'édition, > > in_edition prend l'id de l'utilisateur qui est entrain de modifier les > > données. Il faut à ce moment là autoriser le formulaire correspondant > > à l'article en question pour cet utilisateur seulement. > > > Un autre moyen, serait de conserver une trace de totues les > > modifications da > > > On 9 juin, 09:29, Marc MENDEZ <[EMAIL PROTECTED]> wrote: > > >> Bonjour, > > >> Je commence à me plonger dans CakePHP dans l'optique de la réécriture > >> d'une application métier. > >> J'aimerais savoir comment cakePHP gère l'aspect "multi utilisateur". A > >> savoir, on affiche des données à un instant T, on les modifie à l'écran > >> et on les enregistre. Sauf qu'entre temps, un utilisateur a également > >> modifié ces données. Que se passe-t-il ? La règle du dernier qui a parlé > >> à raison ? Un message d'erreur ? > > >> Merci de vos réponses. --~--~---------~--~----~------------~-------~--~----~ Groupe "Cakephp-fr". Adresse : [email protected] Pour résilier : [EMAIL PROTECTED] Pour les options : http://groups.google.com/group/cakephp-fr?hl=fr -~----------~----~----~----~------~----~------~--~---
