Dans les wiki sans mysql (avec des petits .txt), comment sont gérés les
droits d'accès aux différents articles: que se passe-t-il si quelqu'un
ouvre un article en edition, pendant que quelqu'un d'autre travaille
dessus ? Le deuxième va travailler sur une version antérieure à celle
uploadée par le premier; les modifs du premier seront alors détruites,,,
non ?
Une solution consisterait à changer les droits (chmod 444) des .txt lors
de l'ouverture pour édition, et chmoder en 666 lors du upload, mais que
se passe-t-il si quelqu'un abandone son édition sans uploader ?
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
dmetzler
Ca ne change rien que ce soit sous MySQL ou dans des fichiers textes.
Ca s'appelle la concurrence et c'est un problème avec de multiples solutions.
Quand quelqu'un édite un enregistrements/page tu peux faire plusieurs choses : - ne rien faire - bloquer l'enregistrement en édition
Le deuxième cas garantit que le fichier ne sera pas modifié par quelqu'un d'autre et garantit l'intégrité.
Dans le premier cas, un personne peut à son tour éditer le fichier en même temps. Dans ce cas, le premier qui appuie sur "Envoyer" sauvegarde ses modifications. Lorsque le deuxième valide, il y a encore plusieurs possibilités : - soit ses modifications sont sauvegardées et cela écrase les modifications du précédent - soit on l'empêche de faire la modification - soit on détecte que ses modifications ne rentrent pas en conflit avec les modifications précédentes (pas les même lignes par exemple) et ajoute ses modification à celle précédentes. - soit il y a conflit et on lui propose de gérer le conflit en renvoyant une version annotée.
C'est tout le problème des travaux en groupe, notamment pour la gestion de configuration avec CVS par exemple.
Dans un wiki, il faudra choisir la manière dont tu vas gérer tout ça en fonction de tes besoins.
Ca ne change rien que ce soit sous MySQL ou dans des fichiers textes.
Ca s'appelle la concurrence et c'est un problème avec de multiples
solutions.
Quand quelqu'un édite un enregistrements/page tu peux faire plusieurs
choses :
- ne rien faire
- bloquer l'enregistrement en édition
Le deuxième cas garantit que le fichier ne sera pas modifié par
quelqu'un d'autre et garantit l'intégrité.
Dans le premier cas, un personne peut à son tour éditer le fichier en
même temps. Dans ce cas, le premier qui appuie sur "Envoyer"
sauvegarde ses modifications.
Lorsque le deuxième valide, il y a encore plusieurs possibilités :
- soit ses modifications sont sauvegardées et cela écrase les
modifications du précédent
- soit on l'empêche de faire la modification
- soit on détecte que ses modifications ne rentrent pas en conflit
avec les modifications précédentes (pas les même lignes par exemple)
et ajoute ses modification à celle précédentes.
- soit il y a conflit et on lui propose de gérer le conflit en
renvoyant une version annotée.
C'est tout le problème des travaux en groupe, notamment pour la
gestion de configuration avec CVS par exemple.
Dans un wiki, il faudra choisir la manière dont tu vas gérer tout ça
en fonction de tes besoins.
Ca ne change rien que ce soit sous MySQL ou dans des fichiers textes.
Ca s'appelle la concurrence et c'est un problème avec de multiples solutions.
Quand quelqu'un édite un enregistrements/page tu peux faire plusieurs choses : - ne rien faire - bloquer l'enregistrement en édition
Le deuxième cas garantit que le fichier ne sera pas modifié par quelqu'un d'autre et garantit l'intégrité.
Dans le premier cas, un personne peut à son tour éditer le fichier en même temps. Dans ce cas, le premier qui appuie sur "Envoyer" sauvegarde ses modifications. Lorsque le deuxième valide, il y a encore plusieurs possibilités : - soit ses modifications sont sauvegardées et cela écrase les modifications du précédent - soit on l'empêche de faire la modification - soit on détecte que ses modifications ne rentrent pas en conflit avec les modifications précédentes (pas les même lignes par exemple) et ajoute ses modification à celle précédentes. - soit il y a conflit et on lui propose de gérer le conflit en renvoyant une version annotée.
C'est tout le problème des travaux en groupe, notamment pour la gestion de configuration avec CVS par exemple.
Dans un wiki, il faudra choisir la manière dont tu vas gérer tout ça en fonction de tes besoins.
Bruno.L
Ca ne change rien que ce soit sous MySQL ou dans des fichiers textes.
mysql ne gère pas ces problème de concurence ? j'imaginais qu'une base de donnée le faisait,,, où est l'avantage de mysql alors ?
Ca s'appelle la concurrence et c'est un problème avec de multiples solutions.
Quand quelqu'un édite un enregistrements/page tu peux faire plusieurs choses : - ne rien faire - bloquer l'enregistrement en édition
imaginons que je choisisse de bloquer l'edition d'un enregistrement qui est déjà en édition (en mettant un chmod 444 sur le .txt): - comment gérer que c'est bien la personne qui l'a ouvert en premier qui aurra droit à l'enregistrer (session? adresse IP?) - si cette personne abandonne son édition, comment 'réouvrir' le petit .txt (chmod 666)?
merci pour vos avis Bruno
Ca ne change rien que ce soit sous MySQL ou dans des fichiers textes.
mysql ne gère pas ces problème de concurence ?
j'imaginais qu'une base de donnée le faisait,,,
où est l'avantage de mysql alors ?
Ca s'appelle la concurrence et c'est un problème avec de multiples
solutions.
Quand quelqu'un édite un enregistrements/page tu peux faire plusieurs
choses :
- ne rien faire
- bloquer l'enregistrement en édition
imaginons que je choisisse de bloquer l'edition d'un enregistrement qui
est déjà en édition (en mettant un chmod 444 sur le .txt):
- comment gérer que c'est bien la personne qui l'a ouvert en premier qui
aurra droit à l'enregistrer (session? adresse IP?)
- si cette personne abandonne son édition, comment 'réouvrir' le petit
.txt (chmod 666)?
Ca ne change rien que ce soit sous MySQL ou dans des fichiers textes.
mysql ne gère pas ces problème de concurence ? j'imaginais qu'une base de donnée le faisait,,, où est l'avantage de mysql alors ?
Ca s'appelle la concurrence et c'est un problème avec de multiples solutions.
Quand quelqu'un édite un enregistrements/page tu peux faire plusieurs choses : - ne rien faire - bloquer l'enregistrement en édition
imaginons que je choisisse de bloquer l'edition d'un enregistrement qui est déjà en édition (en mettant un chmod 444 sur le .txt): - comment gérer que c'est bien la personne qui l'a ouvert en premier qui aurra droit à l'enregistrer (session? adresse IP?) - si cette personne abandonne son édition, comment 'réouvrir' le petit .txt (chmod 666)?
merci pour vos avis Bruno
dmetzler
MySQL gère la concurrence au moment où tu fais un INSERT, c'est à dire une fois que la personne a appuyé sur "Valider". Mais le mode Web, c'est un fonctionnement asynchrone. Tu envois le formulaire et tu attends qu'il te revienne... Il peut ne jamais te revenir par exemple. Il n'y a plus de connexion SQL au moment même de l'édition.
Il existe des moyen pour faire des locks, mais je crois que MySQL est pas super fort pour ça. Le lock doit être au niveau de la table et pas de l'enregistrement (corrigez moi si je me trompe surtout !). Ce qui fait que si tu fais un lock, personne ne peut modifier d'autre enregistrement de la même table en même temps.
Ensuite pour bloquer l'édition, tu soulève effectivement un problème, toujours du au fait que l'édition web est asynchrone : un fois que le fichier est en édition, il peut ne jamais être validé. Il faudrait dans ce cas utiliser un autre fichier qui recense les différents utilisateurs qui éditent les fichiers. Tu n'aurais alors plus besoin de passer par les appels systèmes chmod car tu gère toi même les droits.
Pour moi, la meilleure solution reste quand même celle proche de CVS. Effectivement, il arrive rarement que deux utilisateurs modifient la même section de page en même temps (ça arrive, mais la plupart du temps ça n'arrive pas). Donc c'est le cas "rare" qu'il faut gérer en gérant les conflits qu'il pourrait y avoir.
Exemple : tu édites une page et au moment de valider, le système te dit : Attention, le fichier a été modifié par qqn et est en conflit avec tes modifications ! Tiens revoilà le fichier et j'ai surligné les parties en conflit : à toi de te débrouiller maintenant, moi je sais pas faire.
MySQL gère la concurrence au moment où tu fais un INSERT, c'est à
dire une fois que la personne a appuyé sur "Valider". Mais le mode
Web, c'est un fonctionnement asynchrone. Tu envois le formulaire et tu
attends qu'il te revienne... Il peut ne jamais te revenir par exemple.
Il n'y a plus de connexion SQL au moment même de l'édition.
Il existe des moyen pour faire des locks, mais je crois que MySQL est
pas super fort pour ça. Le lock doit être au niveau de la table et
pas de l'enregistrement (corrigez moi si je me trompe surtout !). Ce
qui fait que si tu fais un lock, personne ne peut modifier d'autre
enregistrement de la même table en même temps.
Ensuite pour bloquer l'édition, tu soulève effectivement un
problème, toujours du au fait que l'édition web est asynchrone : un
fois que le fichier est en édition, il peut ne jamais être validé.
Il faudrait dans ce cas utiliser un autre fichier qui recense les
différents utilisateurs qui éditent les fichiers. Tu n'aurais alors
plus besoin de passer par les appels systèmes chmod car tu gère toi
même les droits.
Pour moi, la meilleure solution reste quand même celle proche de CVS.
Effectivement, il arrive rarement que deux utilisateurs modifient la
même section de page en même temps (ça arrive, mais la plupart du
temps ça n'arrive pas). Donc c'est le cas "rare" qu'il faut gérer en
gérant les conflits qu'il pourrait y avoir.
Exemple : tu édites une page et au moment de valider, le système te
dit : Attention, le fichier a été modifié par qqn et est en conflit
avec tes modifications ! Tiens revoilà le fichier et j'ai surligné
les parties en conflit : à toi de te débrouiller maintenant, moi je
sais pas faire.
MySQL gère la concurrence au moment où tu fais un INSERT, c'est à dire une fois que la personne a appuyé sur "Valider". Mais le mode Web, c'est un fonctionnement asynchrone. Tu envois le formulaire et tu attends qu'il te revienne... Il peut ne jamais te revenir par exemple. Il n'y a plus de connexion SQL au moment même de l'édition.
Il existe des moyen pour faire des locks, mais je crois que MySQL est pas super fort pour ça. Le lock doit être au niveau de la table et pas de l'enregistrement (corrigez moi si je me trompe surtout !). Ce qui fait que si tu fais un lock, personne ne peut modifier d'autre enregistrement de la même table en même temps.
Ensuite pour bloquer l'édition, tu soulève effectivement un problème, toujours du au fait que l'édition web est asynchrone : un fois que le fichier est en édition, il peut ne jamais être validé. Il faudrait dans ce cas utiliser un autre fichier qui recense les différents utilisateurs qui éditent les fichiers. Tu n'aurais alors plus besoin de passer par les appels systèmes chmod car tu gère toi même les droits.
Pour moi, la meilleure solution reste quand même celle proche de CVS. Effectivement, il arrive rarement que deux utilisateurs modifient la même section de page en même temps (ça arrive, mais la plupart du temps ça n'arrive pas). Donc c'est le cas "rare" qu'il faut gérer en gérant les conflits qu'il pourrait y avoir.
Exemple : tu édites une page et au moment de valider, le système te dit : Attention, le fichier a été modifié par qqn et est en conflit avec tes modifications ! Tiens revoilà le fichier et j'ai surligné les parties en conflit : à toi de te débrouiller maintenant, moi je sais pas faire.
Bruno.L
Exemple : tu édites une page et au moment de valider, le système te dit : Attention, le fichier a été modifié par qqn et est en conflit avec tes modifications ! Tiens revoilà le fichier et j'ai surligné les parties en conflit : à toi de te débrouiller maintenant, moi je sais pas faire.
dans ce cas, le plus simple serait de diviser la page en petits articles, chacun éditables séparéments (comme wikidepia d'ailleurs ;-). Ce qui m'évite de devoir utiliser une gestion 'à la CVS', technique que je ne connais pas.
imaginons alors, au momment où un visiteur prends un article pour l'éditer, le PHP crée un petit fichier de lock (du même nom que l'article avec un ~). On pourait imaginer que l'heure de création de ce petit fichier déterminerait effectivement le lock: Ceci pour éviter le problèmes de lock intempestifs liés à aux abandons d'édition.
ok! ca avance ;-) et on peut même se dire qu'à priori si quelqu'un prend un article en édition c'est pour le modifier, et qu'il n'y aura que de rares abandons (sauf accidents)
en tous cas merci pour ta réponse qui m'a bien guidée :-)
Bruno
Exemple : tu édites une page et au moment de valider, le système te
dit : Attention, le fichier a été modifié par qqn et est en conflit
avec tes modifications ! Tiens revoilà le fichier et j'ai surligné
les parties en conflit : à toi de te débrouiller maintenant, moi je
sais pas faire.
dans ce cas, le plus simple serait de diviser la page en petits
articles, chacun éditables séparéments (comme wikidepia d'ailleurs ;-).
Ce qui m'évite de devoir utiliser une gestion 'à la CVS', technique que
je ne connais pas.
imaginons alors, au momment où un visiteur prends un article pour
l'éditer, le PHP crée un petit fichier de lock (du même nom que
l'article avec un ~). On pourait imaginer que l'heure de création de ce
petit fichier déterminerait effectivement le lock: Ceci pour éviter le
problèmes de lock intempestifs liés à aux abandons d'édition.
ok! ca avance ;-) et on peut même se dire qu'à priori si quelqu'un prend
un article en édition c'est pour le modifier, et qu'il n'y aura que de
rares abandons (sauf accidents)
en tous cas merci pour ta réponse qui m'a bien guidée :-)
Exemple : tu édites une page et au moment de valider, le système te dit : Attention, le fichier a été modifié par qqn et est en conflit avec tes modifications ! Tiens revoilà le fichier et j'ai surligné les parties en conflit : à toi de te débrouiller maintenant, moi je sais pas faire.
dans ce cas, le plus simple serait de diviser la page en petits articles, chacun éditables séparéments (comme wikidepia d'ailleurs ;-). Ce qui m'évite de devoir utiliser une gestion 'à la CVS', technique que je ne connais pas.
imaginons alors, au momment où un visiteur prends un article pour l'éditer, le PHP crée un petit fichier de lock (du même nom que l'article avec un ~). On pourait imaginer que l'heure de création de ce petit fichier déterminerait effectivement le lock: Ceci pour éviter le problèmes de lock intempestifs liés à aux abandons d'édition.
ok! ca avance ;-) et on peut même se dire qu'à priori si quelqu'un prend un article en édition c'est pour le modifier, et qu'il n'y aura que de rares abandons (sauf accidents)
en tous cas merci pour ta réponse qui m'a bien guidée :-)
Bruno
ph-m
Exemple : tu édites une page et au moment de valider, le système te dit : Attention, le fichier a été modifié par qqn et est en conflit avec tes modifications ! Tiens revoilà le fichier et j'ai surligné les parties en conflit : à toi de te débrouiller maintenant, moi je sais pas faire.
dans ce cas, le plus simple serait de diviser la page en petits articles, chacun éditables séparéments (comme wikidepia d'ailleurs ;-). Ce qui m'évite de devoir utiliser une gestion 'à la CVS', technique que je ne connais pas.
imaginons alors, au momment où un visiteur prends un article pour l'éditer, le PHP crée un petit fichier de lock (du même nom que l'article avec un ~). On pourait imaginer que l'heure de création de ce petit fichier déterminerait effectivement le lock: Ceci pour éviter le problèmes de lock intempestifs liés à aux abandons d'édition.
ok! ca avance ;-) et on peut même se dire qu'à priori si quelqu'un prend un article en édition c'est pour le modifier, et qu'il n'y aura que de rares abandons (sauf accidents)
en tous cas merci pour ta réponse qui m'a bien guidée :-)
sinon je te conseille ce wiki sans base de données : dokuwiki http://wiki.splitbrain.org/wiki:dokuwiki
a+ ph-m
Exemple : tu édites une page et au moment de valider, le système te
dit : Attention, le fichier a été modifié par qqn et est en conflit
avec tes modifications ! Tiens revoilà le fichier et j'ai surligné
les parties en conflit : à toi de te débrouiller maintenant, moi je
sais pas faire.
dans ce cas, le plus simple serait de diviser la page en petits
articles, chacun éditables séparéments (comme wikidepia d'ailleurs ;-).
Ce qui m'évite de devoir utiliser une gestion 'à la CVS', technique que
je ne connais pas.
imaginons alors, au momment où un visiteur prends un article pour
l'éditer, le PHP crée un petit fichier de lock (du même nom que
l'article avec un ~). On pourait imaginer que l'heure de création de ce
petit fichier déterminerait effectivement le lock: Ceci pour éviter le
problèmes de lock intempestifs liés à aux abandons d'édition.
ok! ca avance ;-) et on peut même se dire qu'à priori si quelqu'un prend
un article en édition c'est pour le modifier, et qu'il n'y aura que de
rares abandons (sauf accidents)
en tous cas merci pour ta réponse qui m'a bien guidée :-)
sinon je te conseille ce wiki sans base de données : dokuwiki
http://wiki.splitbrain.org/wiki:dokuwiki
Exemple : tu édites une page et au moment de valider, le système te dit : Attention, le fichier a été modifié par qqn et est en conflit avec tes modifications ! Tiens revoilà le fichier et j'ai surligné les parties en conflit : à toi de te débrouiller maintenant, moi je sais pas faire.
dans ce cas, le plus simple serait de diviser la page en petits articles, chacun éditables séparéments (comme wikidepia d'ailleurs ;-). Ce qui m'évite de devoir utiliser une gestion 'à la CVS', technique que je ne connais pas.
imaginons alors, au momment où un visiteur prends un article pour l'éditer, le PHP crée un petit fichier de lock (du même nom que l'article avec un ~). On pourait imaginer que l'heure de création de ce petit fichier déterminerait effectivement le lock: Ceci pour éviter le problèmes de lock intempestifs liés à aux abandons d'édition.
ok! ca avance ;-) et on peut même se dire qu'à priori si quelqu'un prend un article en édition c'est pour le modifier, et qu'il n'y aura que de rares abandons (sauf accidents)
en tous cas merci pour ta réponse qui m'a bien guidée :-)
sinon je te conseille ce wiki sans base de données : dokuwiki http://wiki.splitbrain.org/wiki:dokuwiki
