Bonjour à tous,
Dans mon application, quand un utilisateur est en cours d’édition sur
une
page (vue ‘edit’), je souhaite empêcher (ou afficher un avertissement)
un
autre utilisateur d’accéder à cette page d’édition (je préfère éviter
une
solution prévenant l’écrasement de données seulement au moment où
l’utilisateur soumet les données de son formulaire).
Pour cela mon idée est de mettre un marqueur en base de données quand un
premier utilisateur accède à une page d’édition, et retirer ce marquer
quand
il quitte cette page d’édition. Quand un utilisateur souhaite accéder Ã
une
page d’édition, je le bloque si un tel marqueur existe pour cette page.
Mon problème est de détecter quand un utilisateur quitte une page en
cours
d’édition, car il existe plusieurs façons pour un utilisateur de quitter
cette page : après une sauvegarde réussie, en suivant un lien vers une
autre
page, quand il ferme la fenêtre d’édition dans son navigateur, quand il
ferme son navigateur… J’ai l’impression que c’est impossible en
pratique
de détecter tous ces cas de figure et les reporter au serveur pour
retirer
le marqueur.
Aussi pour détecter si un utilisateur est toujours sur sa vue edit, je
pense
ajouter une information “date” aux marqueurs en BDD, et mettre un
periodically_call_remote dans mes vues edit qui rafraichirait la date du
marquer correspondant. Je ne bloquerais l’accès à une page d’édition
pour un
autre utilisateur que si le marqueur correspondant a une date
relativement
récente.
Ça me paraît faisable mais ça reste un peu alambiqué, aussi je suis
ouvert Ã
toute suggestion pour simplifier cette implémentation voir utiliser une
autre façon de faire 
Cordialement,
Florent
Bonjour Florent,
Sincèrement c’est la seule vraie solution pas trop moche à ton problème.
Cordialement,
Michel B.
2010/3/16 Florent F.rent [email protected]
C'est ce que je pensais : en effet il n'y a que très peu de
lignes de
codes spécifiques en fait.
Par contre, comme d'habitude, la solution passe parfois par la question
"ai-je vraiment besoin de ça ?". Si tu estimes le cas possible
(facile
: si tu as plusieurs utilisateurs, c'est toujours possible) mais peu
probable, tu peux te limiter à détecter le
problème, mais à ne pas le
corriger.
Par exemple, quand tu entres en édition, tu lis la version de
l'enregistrement. Juste avant de sauver, tu vérifie qu'il n'a pas
bougé. si il a bougé entre temps, tu te limites à
dire "enregistrement
modifié par ailleurs, je refuse d'écraser", et c'est aux
utiliteurs de
se débrouiller.
C'est évidemment bcp plus sommaire comme solution, mais si
ça suffit à
ton cas (sans compter le fait d'être indépendant de
Javascript...)
gUI
Michel B. a écrit :
Bonjour Florent,
Sincèrement c'est la seule vraie solution pas trop moche à
ton problème.
Cordialement,
Michel B.
2010/3/16 Florent F.rent
<[email protected]>
Bonjour à tous,
Dans mon application, quand un utilisateur est en cours
d'édition sur une page (vue 'edit'), je souhaite empêcher
(ou afficher
un avertissement) un autre utilisateur d'accéder à cette
page d'édition
(je préfère éviter une solution prévenant
l'écrasement de données
seulement au moment où l'utilisateur soumet les données de
son
formulaire).
Pour cela mon idée est de mettre un marqueur en base de
données quand un premier utilisateur accède à une
page d'édition, et
retirer ce marquer quand il quitte cette page d'édition. Quand un
utilisateur souhaite accéder à une page d'édition,
je le bloque si un
tel marqueur existe pour cette page.
Mon problème est de détecter quand un utilisateur
quitte une
page en cours d'édition, car il existe plusieurs façons
pour un
utilisateur de quitter cette page : après une sauvegarde
réussie, en
suivant un lien vers une autre page, quand il ferme la fenêtre
d'édition dans son navigateur, quand il ferme son navigateur...
J'ai
l'impression que c'est impossible en pratique de détecter tous
ces cas
de figure et les reporter au serveur pour retirer le marqueur.
Aussi pour détecter si un utilisateur est toujours sur
sa vue
edit, je pense ajouter une information "date" aux marqueurs en BDD, et
mettre un periodically_call_remote dans mes vues edit qui rafraichirait
la date du marquer correspondant. Je ne bloquerais l'accès
à une page
d'édition pour un autre utilisateur que si le marqueur
correspondant a
une date relativement récente.
Ça me paraît faisable mais ça reste un peu
alambiqué, aussi je
suis ouvert à toute suggestion pour simplifier cette
implémentation
voir utiliser une autre façon de faire :)
Cordialement,
Florent
--
Vous avez reçu ce message, car vous
êtes
abonné au groupe "Railsfrance" de Google G..
Pour transmettre des messages à ce groupe, envoyez un e-mail
à
l'adresse [email protected]
Pour résilier votre abonnement envoyez un e-mail à
l'adresse [email protected]
--
Vous avez reçu ce message, car vous êtes abonné au
groupe "Railsfrance"
de Google G..
Pour transmettre des messages à ce groupe, envoyez un e-mail
à
l'adresse [email protected]
Pour résilier votre abonnement envoyez un e-mail à
l'adresse
[email protected]
–
Vous avez reçu ce message, car vous êtes abonné au groupe
"Railsfrance" de Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse
[email protected]
Merci Michel & Guillaume pour vos réponses ! Après consultation des
utilisateurs de l’appli, ta solution Guillaume leur suffit. Du coup c’est
celle que j’ai retenue car c’est plus simple à implémenter.
Attention, il faut que tu rendes atomique (c’est à dire ininterruptible)
l’action “je relis pour vérifier que l’enregistrement n’a pas bougé puis
je
savue une nouvelle version”. Je crois que c’est le concept des
transactions
[1] (je l’ai jamais mis en oeuvre mais j’y avais jeté un oeil pour un
projet
perso).
Sinon tu risques le scénario suivant :
A lit l’enregistrement en version x
A édite l’enregistrement
B lit l’enregistrement en version x
B edite l’enregistrement
A vérifie l’enregistrement toujours en x => OK
B vérifie l’enregistrement toujours en x => OK
A sauve et passe en version x+1
B écrase la sauvegard de A et passe aussi en x+1
gUI
[1]
–
Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/
Le 16 mars 2010 12:01, Guillaume B. [email protected] a
écrit
:
il a bougé entre temps, tu te limites à dire “enregistrement modifié par
ailleurs, je refuse d’écraser”, et c’est aux utiliteurs de se débrouiller.
C’est évidemment bcp plus sommaire comme solution, mais si ça suffit à ton
cas (sans compter le fait d’être indépendant de Javascript…)
Merci Michel & Guillaume pour vos réponses ! Après consultation des
utilisateurs de l’appli, ta solution Guillaume leur suffit. Du coup
c’est
celle que j’ai retenue car c’est plus simple à implémenter.
Cordialement,
Florent
Bonjour,
j’arrive un peu tard, mais Rails implémente ça directement :
http://apidock.com/rails/ActiveRecord/Locking/Optimistic
++
David
Le 19 mars 2010 14:53, Florent F.rent [email protected] a écrit :
l’action "je relis pour vérifier que l’enregistrement n’a pas bougé puis je
B vérifie l’enregistrement toujours en x => OK
Effectivement, je n’avais pas pensé à ce cas, merci Guillaume. J’ai
Même si ce n’est pas le cas, je crois que je vais passé outre le cas de
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]
To unsubscribe from this group, send email to railsfrance+
unsubscribegooglegroups.com or reply to this email with the words “REMOVE
ME” as the subject.
–
Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance”
de Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]
To unsubscribe, reply using “remove me” as the subject.
Le 18 mars 2010 02:41, Guillaume B. [email protected] a
écrit
:
perso).
gUI
[1]
ActiveRecord::Transactions::ClassMethods
Effectivement, je n’avais pas pensé à ce cas, merci Guillaume. J’ai
consulté
la page de l’API que tu as pointée, elle dit :
“Both Base#save and Base#destroy come wrapped in a transaction that
ensures
that whatever you do in validations or callbacks will happen under the
protected cover of a transaction.”
J’ai implémenté sous forme de validation la vérification qu’un
enregistrement est toujours en version x, donc si je comprends bien le
texte
la vérification et la sauvegarde ont lieu dans une même transaction.
Même si ce n’est pas le cas, je crois que je vais passé outre le cas de
figure du problème d’un enregistrement (quasi) simultané par 2
utilisateurs,
car dans mon application les fréquences d’enregistrement sont faibles.
Florent
–
Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance”
de Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]
To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.
