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

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D ;) :o :? 8) :lol: :oops: :twisted: :roll: :ours: :fille: :calimero: :saint: :forb: :avocat: :mouton: :rando: :vaudou: :noel: :) :( :shock: :x :P :cry: :excl: :?: :idea: :arrow: :| :sleep: :geek: :blue: :mrgreen:
Voir plus de smileys

Les BBCodes sont activés
[img] est activé
[flash] est désactivé
[url] est activé
Les smileys sont activés

Revue du sujet
   

Étendre la vue Revue du sujet : [mcproposition] Garder un historique et signaler les changements sur les fiches

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

par Claude Mauguier » 09 sept. 2019, 14:47

En tout cas c'est fourni, puisqu'on peut contrôler ligne par ligne. Un bon outil de toute manière.

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

par Dominique » 09 sept. 2019, 08:49

ça m'a l'air bien.
Pour avoir tenté d'utiliser ce genre de sauvegarde sur https://alpages.info c'est très laborieux mais ça sauve quelquefois d'une grosse cata quand on est vraiment bloqué ou qu'on ne comprend pas comment on en est arrivé là.
ça me semble un minimum indispensable pour pouvoir gérer un site.

Merci.

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

par sly » 09 sept. 2019, 04:26

N'ayant pas encore trouvé le temps et le courage de faire l'historisation de mes rêves de toutes les modifications survenues sur refuges.info, mais ne voulant pas non plus que se reproduise le coup de la dernière fois, j'ai codé, sur la suggestion de Dominique et suite à ma simplification de la structure de la base un petit outils (pour les modérateurs uniquement pour l'instant) qui affiche, comme le souhaitait NicoM les (100) dernières modifications survenues sur une fiche de refuges.info.

C'est vraiment basique et pas très beau, une modification même "blanche" (juste d'appuyer sur modifier) générera une ligne dans le tableau, c'est pas forcément terrible pour suivre les dernières modifications, mais en cas de doute, on pourra s'y référer.

J'en affiche 100 pour que ça soit digeste, mais dans la babasse je stocke sans limite de durée à compter de maintenant, que l'on ne peut pour l'instant pas interroger autrement qu'en étant développeur (moi ou Dominique ou leo) mais que je pourrais éventuellement étendre ultérieurement selon besoin.

On y accède dans le menu "gestion" -> "Historique des modifications des points"

- les commentaires ne sont pas concernés
- les messages du forum non plus
- on ne peut faire de recherche par aucun critère (à part votre navigateur qui fera une recherche sur la page)
- on ne peut pas annuler une modification

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

par sly » 05 févr. 2019, 20:28

Ok, merci pour le suivi, j'ai donc trouvé le site actuel de kabano :
https://kabano.org/

Et ben... que dire à part "N'hésitez pas à nous contacter pour nous encourager !" => Bon courage et tiens moi au courant dès qu'il y a un tout petit truc de fonctionnel concernant les cabanes et le versioning, car pour l'instant, ça fait un peu "concept théorique de R&D" ;-)

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

par leosw » 05 févr. 2019, 17:52

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

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

par sly » 05 févr. 2019, 16:17

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 ?

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

par leosw » 05 févr. 2019, 15:59

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

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

par sly » 31 janv. 2019, 10:46

Dominique a écrit :
25 janv. 2019, 16:43
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.
Dominique a écrit :
25 janv. 2019, 16:43
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.

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

par Dominique » 25 janv. 2019, 16:43

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' :ours:, je suis gâté mais peut être une idée pour WRI ?

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

par Claude Mauguier » 25 janv. 2019, 12:38

sly a écrit :
25 janv. 2019, 11:41
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 :ours: 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' :ours:

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

par sly » 25 janv. 2019, 11:41

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...

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

par sly » 21 déc. 2017, 15:01

leosw a écrit :
21 déc. 2017, 14:31
* 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

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

par leosw » 21 déc. 2017, 14:31

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

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

par sly » 21 déc. 2017, 01:08

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

par sly » 23 nov. 2015, 21:27

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) ?

Haut