PHP, MySql et multi utilisateur

[Marc Mendez]

Bonjour,

J'ai une application métier fonctionnant sous Internet, en PHP et MySql.
La première mouture qui fonctionne depuis deux ou trois ans ne se préoccupe
pas du multi utilisateur. En fait, "le dernier qui parle à raison" comme on
dit....

Vu que l'appl fonctionne sous un navigateur, il est difficile de maintenir
un verrou sur les données courament affichées à l'écran. De plus, à la
différence d'autres SGBDR (Oracle par exemple), il n'y a pas de notion de
ROWID permettant de savoir si une données a été modifiée depuis la dernier
consultation (et encore, certains SGBDR ne le changent pas en cas d'update).

Je verrai bien un lock sur les données, avec un timeout sur le serveur
MySql... mais j'en suis au stade pur des supposition. Mes recherches sur le
sujet n'ont pas été concluante.

Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre : niet ;) )

Merci de vos conseils.

[Mickael Wolff]

Bonjour,

Post by Marc Mendez
J'ai une application métier fonctionnant sous Internet, en PHP et MySql.

Aïe. Vous êtes le développeur ?

Post by Marc Mendez
Vu que l'appl fonctionne sous un navigateur, il est difficile de maintenir
un verrou sur les données courament affichées à l'écran. De plus, à la
différence d'autres SGBDR (Oracle par exemple), il n'y a pas de notion de
ROWID permettant de savoir si une données a été modifiée depuis la dernier
consultation (et encore, certains SGBDR ne le changent pas en cas d'update).

Ça n'a rien à voir. De plus, il existe un rowid dans les tables MySQL.

Post by Marc Mendez
Je verrai bien un lock sur les données, avec un timeout sur le serveur
MySql... mais j'en suis au stade pur des supposition. Mes recherches sur le
sujet n'ont pas été concluante.

Mauvaise idée.

Post by Marc Mendez
Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre : niet ;) )

Il faudrait avoir le code sous les yeux pour pouvoir donner un avis
pertinent. À coup sûr il faut sérieusement revoir l'architecture de
l'application pour la rendre multi-utilisateur, et introduire les locks
là où il faut. Et sans que ce ne soit bloquant.

Mais là, ce n'est pas un problème de PHP, mais un problème de design.

[Marc Mendez]

Post by Marc Mendez
Bonjour,

Post by Marc Mendez
J'ai une application métier fonctionnant sous Internet, en PHP et MySql.

Aïe. Vous êtes le développeur ?

De la version courante, non. De la prochaine, en grande partie...

Post by Marc Mendez

Post by Marc Mendez
Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre : niet ;) )

Il faudrait avoir le code sous les yeux pour pouvoir donner un avis
pertinent. À coup sûr il faut sérieusement revoir l'architecture de
l'application pour la rendre multi-utilisateur, et introduire les
locks là où il faut. Et sans que ce ne soit bloquant.

Ma foi, les requetes ne manquent pas. En gros, il y a deux méthodes :

l'une consiste à lire toutes les données nécessaires en début de la page
(elles sont stockées en tableau), et éventuellement de faire les premiers
traitement sur les données. Ensuite, affichage.
Les modifications sont faites en appelant à partir de cette première page,
une autre page qui se charge de récupérer les infos passées en post et fait
les modifs dans la base.

L'autre méthode fonctionne sur une seule et même page qui collecte, affiche
et modifie les données.


Je vois très bien comment conserver le timestamp des lignes éventuellements
(input caché). Ensuite, à moi de m'assurer que les UPDATE fasse une
modification ligne par ligne et pas par lot (sinon impossible de contrôler
le timestamp de chacune... et encore, ça dépendra peut-être du contexte...)

Bref, de toute façon, votre réponse et celle d'autres personnes m'ont
confirmé les solutions à mettre en oeuvre. La réécriture de l'application
est incontournable de toute façon pour ce genre de prise en compte... En
plus, elle doit être réécrite car la structure des données que nous
utilisons ont foncièrement changé et elle ne couvre plus ainsi tous nos
besoins.

Merci de votre réponse !

Post by Marc Mendez
Mais là, ce n'est pas un problème de PHP, mais un problème de design.

[Bruno Desthuilliers]

Post by Marc Mendez
Bonjour,
J'ai une application métier fonctionnant sous Internet, en PHP et MySql.
La première mouture qui fonctionne depuis deux ou trois ans ne se préoccupe
pas du multi utilisateur. En fait, "le dernier qui parle à raison" comme on
dit....
Vu que l'appl fonctionne sous un navigateur, il est difficile de maintenir
un verrou sur les données courament affichées à l'écran. De plus, à la
différence d'autres SGBDR (Oracle par exemple), il n'y a pas de notion de
ROWID permettant de savoir si une données a été modifiée depuis la dernier
consultation (et encore, certains SGBDR ne le changent pas en cas d'update).
Je verrai bien un lock sur les données, avec un timeout sur le serveur
MySql...

C'est peut être un a priori, mais j'aurais pas confiance.

Post by Marc Mendez
mais j'en suis au stade pur des supposition. Mes recherches sur le
sujet n'ont pas été concluante.
Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre : niet ;) )

Ce n'est pas à proprement parler un pb de langage - le pb serait le même
en Perl, en Python, en Ruby, en Java, etc, etc, etc...

Une solution assez simple consiste à utiliser une colonne avec un
timestamp conservant la date de dernière modif. Cette valeur est passée
via un input hidden au formulaire d'édition, et vérifiée au retour du
formulaire pour détecter une modif intervenue entretemps.

[Marc Mendez]

Post by Bruno Desthuilliers
Une solution assez simple consiste à utiliser une colonne avec un
timestamp conservant la date de dernière modif. Cette valeur est
passée via un input hidden au formulaire d'édition, et vérifiée au
retour du formulaire pour détecter une modif intervenue entretemps.

Bonjour,

C'est effectivement une solution à laquelle j'ai pensé. Le timestamp pourra
d'ailleurs être maintenu automatiquement par des triggers.

[Bruno Desthuilliers]

Post by Marc Mendez

Post by Bruno Desthuilliers
Une solution assez simple consiste à utiliser une colonne avec un
timestamp conservant la date de dernière modif. Cette valeur est
passée via un input hidden au formulaire d'édition, et vérifiée au
retour du formulaire pour détecter une modif intervenue entretemps.

Bonjour,
C'est effectivement une solution à laquelle j'ai pensé. Le timestamp pourra
d'ailleurs être maintenu automatiquement par des triggers.

Pas nécessaire si version de MySQL suffisament récente - il suffit de
déclarer correctement le champ pour qu'il se mette à jour tout seul sur
un update.