[mcproposition] Garder un historique et signaler les changements sur les fiches

[NicoM]

Sujet d'origine était : faire apparaître dans nouvelles le changement d'état d'une cabane

J'ai remarqué aujourd'hui que le nombre d'hébergement est passé à 1660 (-1) car l'un d'entres eux est passé dans la catégorie fermée ou détruite (passé de 153 à 154).
Ce n'est qu'une proposition mais serait il intéressant qu'un changement d'état de ouvert à fermé ou son contraire apparaisse dans la page Les nouvelles ?
L'intérêt peut sembler faible à priori mais comme un tel changement peut visiblement arriver sans qu'un nouveau commentaire soit apparu sur la fiche du point ou sur le forum du point cet intérêt n'est peut être pas nul, ou peut être que si


mcwiki mchistorique mcrevision mvsuivi

[sly]

Carrément, c'est une bonne idée et avec plusieurs avantages :

Je me rappel en avoir discuté il y a super longtemps (mais j'ai rien fait depuis et je retrouve plus la discussion sacre-bleu) de l'idée qui était de conserver les actions faites sur les fiches (que ça soit les modérateurs ou l'auteur d'origine de la fiche)

Cela permettait par exemple de revenir en arrière sur une modification si on avait fait une erreur, de revenir (par nostalgie !) sur l'histoire d'une fiche (construite, brulée, reconstruite, agrandie, renarde de chaumaillou abattue ;-(( ) mais aussi, comme tu le proposes, de faire figurer dans les nouvelles les changements sur les fiches.

Aujourd'hui, le seul truc qui se rapproche un tout petit peu de ça c'est l'info "date de dernière mise à jour" pour une fiche. Et bon, c'est pas que ça sert à rien, mais presque si on ne sait pas ce qu'a été la modification !

Plein de bonnes idées donc (13 idées d'amélioration, 8 bugs à corriger) mais il nous manque des développeurs avec du temps ;-(

[Claude Mauguier]

+1
C'est vrai qu'un historique, même laconique, depuis la création de la fiche avec toutes les modifs associées, éviterait déjà les conflits de "paternité" et permettrait de suivre au jour le jour (*) le travail effectué.
Je précise que c'est moi qui ai "fermé" la cabane du Roc de la Pêche, car le fonds de commerce est mis en vente. Ceci étant, les gérants actuels n'ont peut-être pas mis la clef sous la porte, mais j'ai préféré anticiper afin que personne n'aille se casser le nez sur une porte fermée.

P.S.
L'astérisque placé a posteriori à la suite de cette expression vise à faire remarquer l'omission, à laquelle je m'astreins, de l'expression favorite correspondante, utilisée par la langue de bois journalistico-communiquante : "au quotidien", déjà baveuse en soi et promue au rang d'unicum ineffable et bien "dans la ligne" du P.C.U.

[leosw]

Salut à tous,

Je fais remonter le sujet.

Pour ce qui est de l'aspect technique (comme sly le proposait sur une discussion que j'ai effacé cause doublon), on a de la discussion.

Pour ma part, je pense que la méthode est d'ajouter deux tables : fiches_histo et commentaires_histo dans lesquels on a exactement la même topologie que la table normale mais avec l'ajout d'un champ "révision".

Du coup on peut, pour chaque fiche (ou commentaire) sortir toutes les versions précédentes ordonnées.

Léo

[sly]

Ma suggestion à moi serait de n'avoir qu'une seule table "point" et une seule table commentaire avec un champs qui s'appel "date de dernière modif" un champ binaire "actif/inactif", un champ "auteur de cette version" et un champ version

Par défaut, tout le site ne fait toujours que "and actif"

Et lorsque l'on veut revenir à une version antérieure on fait un :
update point set actif=false where id=x and actif
puis
update point set actif=true where version=y and id=x
sur la version vers laquelle on souhaite retourner.


A chaque modif on ferait un truc genre :
insert into point (select * from point where id=x and actif) -> copie de la version actuelle de la fiche


Un courageux pour regarder comment c'est fait par "les autres" dans le monde des wiki (genre mediawiki) ?

[sly]

A défaut de voir comment font les autres, en cherchant des idées et des "best practices" je suis tombé sur cet article que je note ici quand je me plongerais là dedans :
https://esj.com/articles/2011/03/01/fiv ... ables.aspx

L'idée suggérée (dans sa version simple) reprend le principe que j'évoquais avec une seule table : existence dans la même table d'autant de lignes qu'il y a eu de modification d'une fiche. Sauf que je n'avais pas pensé que l'id qui était unique allait être différent pour chaque version d'une fiche et qu'il faudrait donc ajouter un champ pour garder le lien vers la précédente version. Dans l'article, l'idée est que le clé primaire n'est plus le id_point mais le couple id_point,date_modification de sorte que l'on puisse garder le même id pour toutes les versions d'un point, seul le plus récent étant l'actif."Actif" n'ayant plus de raison d'être un champ puisque le plus récent étant l'actif. Une modif consiste alors à dupliquer l'actif et mettre à jour la date_modification, il devient alors automatiquement le nouvel actif.

Il y aurait donc a ajouter seulement 3 champs : un champ date_modif, auteur_modif et pourquoi pas un champs "raison_modif"
La clé primaire étant alors id/date_modif et le champs d'auto-incrément restant valable pour les ajouts de nouveaux points.

A creuser parce que ça n'est pas tout à fait fini: les commentaires sont rattachés à un id de de fiche, il faudrait voir ce qu'on fait lorsqu'un commentaire est modifié/supprimé et à quelle(s) version de fiche ancienne il se rattache.
Et p'tet que les messages forum on va pas trop y toucher !

Bref, structurellement je vois à peu près comment faire, le code existant passant tout par les fonctions (modèle ? ) spécial "points" ça devrait pas trop faire de code à corriger/tester. Mais alors coté interface, faut pouvoir voir les anciennes versions, afficher les différences, et pouvoir revenir à n'importe quelle ancienne version.

Y'a du taf

[leosw]

Salut,

J'ai implémenté ce mécanisme dans feu Kabano (que j'essaye de recoder rapidement).
En gros, la méthode est d'avoir deux tables :

* Liste des points (contient les données qui ne changent pas entre les versions : id, date de création, ainsi qu'un champ archive qui permet de cacher un point)
* Versions de chaque point (contient les données qui peuvent être éditées, ainsi qu'un champ archive, qui est vrai pour toutes les versions anciennes)

Cette topologie permet de restaurer une ancienne version facilement, et d'avoir une recherche dans la base hyper efficace.

Comme c'est un peu lourd, les commentaires ne sont que dans une table, et un utilisateur ne pourra pas modifier un commentaire mais l'archiver et en publier un nouveau.

Léo

[sly]

* Liste des points (contient les données qui ne changent pas entre les versions : id, date de création, ainsi qu'un champ archive qui permet de cacher un point)
* Versions de chaque point (contient les données qui peuvent être éditées, ainsi qu'un champ archive, qui est vrai pour toutes les versions anciennes)

Avec ta structure elle est où la date de modification ? J'imagine dans la table "versions des points" ?
En tout cas le principe est similaire, mais la méthode que j'ai indiqué économise une table. La date de création étant simplement la date de la première modif, et le flag "archive" étant implicite en se servant des dates anciennes.

Mais on reste sur le même principe. L'autre option que j'ai pu lire étant la solution de double table style "points_courant" "point_historique" qui fait maigrir la table des points actifs mais qui oblige dans chaque bout de code de définir une table qu'on attaque mutante.

Les débats ne tranchent pas, selon les cas les deux se font

[sly]

Suite au terrible drame de la perte de donnée ici :
http://www.refuges.info/forum/viewtopic.php?f=4&t=282

je vais reprendre cette proposition et tenter de mettre ça en service, rien que d'imaginer tout ce que ça implique, j'ai la trouille sur le temps passé, mais je vais faire ça proprement et à mon rythme et je compte sur vous pour remonter les bugs. Je vous tiens informé de chaque test.
Temps de travail estimé : ~8 jours. Tant disponible du sly : 2heures par mois. Temps avant mise en service : je préfère pas faire la division...

[Claude Mauguier]

Suite au terrible drame de la perte de donnée ici :
http://www.refuges.info/forum/viewtopic.php?f=4&t=282

je vais reprendre cette proposition et tenter de mettre ça en service, rien que d'imaginer tout ce que ça implique, j'ai la trouille sur le temps passé, mais je vais faire ça proprement et à mon rythme et je compte sur vous pour remonter les bugs. Je vous tiens informé de chaque test.
Temps de travail estimé : ~8 jours. Tant disponible du sly : 2heures par mois. Temps avant mise en service : je préfère pas faire la division...

Comme un c'est pas trop délicat ni compliqué, je vais proposer la méthode con et basique de sauvegarde élémentaire, avec empilement successif d'un état "N" des points à une date "T", soit N1T1 + N2T2 + NxTx.... dans un DD externe dédié.

Première critique : Où stocker tout ça ? Combien de Giga/Téraoctets "pèsent" l'ensemble des points WRI ?
Deuxième critique : on n'a pas une vision dynamique, c'est à dire quoi a été fait et par qui et quand dans l'intervalle de temps, mais une succession de clichés espacés (reste à définir l'unité d'espace) dans le temps...Pas la panacée, mais on voit ce qui a changé ou pas , au moins en faisant bêtement N2T2 - N1T1.

Voilà, cher public, le dernier pavé de l'

[Dominique]

C'est pas un truc qui fait papa/maman mais qui permet de ne pas se retrouver en slip qaund on a perdu des infos:
Sur chemineur, je log dans un fichier l'état SQL du point concerné avant toute modification : http://chemineur.fr/EDIT.log
Ce n'est pas un modèle de programmation avancée (quoi que le NoSQL !!!) mais ça demande 3 lignes et 20 minutes pour être réalisé).
pas trop facile de retrouver ses petits ni récupérer 100 points perdus mais, avec un peu d'habitude, on peut reconstituer un commentaire effacé sans aller chercher la sauvegarde.
Amélioration dans une future version de chemineur : 1 fichier par point, ce sera plus facile d'y retrouver ses petits.

Il est vrai que dans chemineur, avec un seul modérateur d'une méticulosité d' , je suis gâté mais peut être une idée pour WRI ?

[sly]

mais ça demande 3 lignes et 20 minutes pour être réalisé).

Ouais mais on en a pour son temps !
Après faut gérer la taille du log, les photos n'y seront pas.

peut être une idée pour WRI ?

Ouais, je vais p'tet y faire, c'est tellement pas long que ça pourrait aider, mais j'ai peur que ça me démotive à passer à un vrai historique, que tout modérateur peut consulter, activer, avec photos et top joli !
Mais comme c'est pas demain la veille...
un chien vaut mieux que deux kilos de rat

Après, refuges.info total c'est ~20Go (ha tient quand même, il a pris du gras le p'tit) ! je peux aussi trouver une place, annuelle, en plus des sauvegardes sur un mois pour garder chaque 1er janvier un full truc complet à vie.

[leosw]

Salut à tous,

Je me permet juste de dire que l'archi espérée niveau base de donnée va ressembler à ce que je fais sur Kabano.
Après maintes réflexions, voici l'archi SQL aujourd'hui :

table cabane -- Toutes les données ici sont les données qui permettent d'identifier un point, et qui ne seront pas historisée
colonne identifiant
colonne public -- Est-ce que le point est public ?

table cabane_traduite -- Spécifique à Kabano : chaque cabane peut être traduite dans plusieurs langue, mais il y n'y a qu'un identifiant par langue
colonne identifiant
colonne id_cabane -- L'identifiant vers la table précédente
colonne langue

table cabane_source -- Spécifique à Kabano : chaque fiche traduite peut provenir de différentes sources : WRI, Kabano...
colonne identifiant
colonne id_langue -- L'identifiant vers la table précédente
colonne source
colonne auteur

table cabane_versions -- Le gros du gros, toutes les données historisées
colonne identifiant
colonne id_source -- L'identifiant vers la table précédente
colonne archive -- Est-ce que cette version de la fiche est la version active ?
colonne numero_version
colonne coordonnées
colonne infoX...

Pour le moment je trouve que j'ai assez de liberté avec ça

Léo

[sly]

Merci léo pour ta vision des choses !
ça peut donner des idées, même si étant têtu, je ne pense pas faire comme ça . Mais je reste à l'écoute, si ça simplifie le code, je pourrais choisir de passer à 2 tables plutôt qu'1.
Mais je constate que ta nouvelle structure économise une duplication des champs de cabane (genre altitude) par rapport à la version que tu avais suggéré ci-avant. Toutefois, ton champs "auteur" semble indiquer qu'il ne peut être différent pour chaque révision ?


Sinon, kabano c'est disponible quelque part publiquement que l'on puisse juger sur pièce de la pertinence de ce schéma ?

[leosw]

Salut Sylvain,

Après nombreuses réflexion, le schéma a évolué en effet.

Pour chaque fiche, il y a en effet un seul auteur, et une autre table que je n'ai pas mentionné qui liste les "contributeurs". Je ne stocke pas le contributeur à l'origine de la modification dans cette table, parce que il y a aussi au milieu des sources externes, mais ici ça peut être bien utile.

Le code est là : https://git.lstronic.com/gogs/leo/kabano
Mais il n'est pas du tout fini évidement, ce SQL n'est même pas implémenté pour les données géographiques, uniquement pour le wiki et le blog (c'est la même chose, il n'y a juste pas le champ géographique).

Léo