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 ;) )
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mickael Wolff
Bonjour,
J'ai une application métier fonctionnant sous Internet, en PHP et MySql.
Aïe. Vous êtes le développeur ?
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.
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.
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.
J'ai une application métier fonctionnant sous Internet, en PHP et MySql.
Aïe. Vous êtes le développeur ?
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.
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.
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.
J'ai une application métier fonctionnant sous Internet, en PHP et MySql.
Aïe. Vous êtes le développeur ?
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.
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.
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.
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.
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.
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.
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.
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.
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
Bruno Desthuilliers wrote:
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 wrote:
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.
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.
Marc Mendez
Mickael Wolff wrote:
Bonjour,
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...
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 !
Mais là, ce n'est pas un problème de PHP, mais un problème de design.
Mickael Wolff wrote:
Bonjour,
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...
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 !
Mais là, ce n'est pas un problème de PHP, mais un problème de design.
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...
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 !
Mais là, ce n'est pas un problème de PHP, mais un problème de design.
Bruno Desthuilliers
Bruno Desthuilliers wrote:
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.
Bruno Desthuilliers wrote:
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.
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.
