Calcul automatisé des dates de création et dernière modification

[alhyss]

Plume dispose désormais d'un petit système pour automatiser la gestion des dates de création et modification :

• Côté serveur, il repose sur un mécanisme classique et assez rudimentaire à base de déclencheurs et déclencheurs sur évènements, qui est pour l'heure intégré à PlumePg. Il est désactivé par défaut et son activation est complètement optionnelle. Les dates sont simplement enregistrées dans une table. Plus de détails dans la documentation technique.
• Côté plugin QGIS, c'est encore une fois le mécanisme de calcul côté serveur qui permet d'importer les dates dans les fiches de métadonnées. Pour la métadonnée date de création / dct:created, il serait assez logique d'utiliser le mode de calcul automatique 'new' (le calcul est réalisé uniquement lorsque la fiche de métadonnées est vierge, étant entendu que si cette information n'était pas disponible à la création de la fiche, elle ne le sera jamais). Pour la métadonnée date de dernière modification / dct:modified, 'auto' peut être adapté dans le cas général (calcul à chaque chargement de la fiche). Au gré de la personne qui crée le modèle, évidemment.

Il n'y a plus rien d'autre à faire pour que ce système soit opérationnel que finaliser l'implémentation du mécanisme de calcul côté serveur - cf. issue #23.

Un point à trancher par le sous-groupe Métadonnées. Ce que j'ai ajouté à PlumePg pour l'enregistrement des dates n'a pas de dépendance vis-à-vis du reste[^timestamp-to-metadata] et pourrait constituer en soi un outil viable pour un service qui souhaiterait tracer les dates de création/dernière modification sans pour autant être intéressé par le coeur des fonctionnalités de Plume. J'hésite donc à en faire une extension indépendante. Il y aurait évidemment des inconvénients :

• Ce serait une extension de plus à gérer pour les services qui ont besoin de l'ensemble.
• Ça impliquerait probablement un schéma z_... de plus pour stocker la table et les fonctions...
• Le stockage des dates dans la table stamp_timestamp n'est pas réellement pérenne. Comme les tables sont identifiées par leur OID (ce qui permet d'éviter tous les problèmes de changement de nom, changement de schéma, etc.), l'information est perdue lorsque la table est supprimée, y compris en cas de sauvegarde/restauration. J'ai considéré que c'était acceptable dans la mesure où ces dates ont vocation à être intégrées dans les fiches de métadonnées, qui elles sont pérennes, mais ça ne vaut que si le service utilise également Plume...

[^timestamp-to-metadata]: Hormis la fonction stamp_timestamp_to_metadata() et le déclencheur de même nom, eux resteront dans PlumePg quoi qu'il arrive et l'extension de gestion des dates serait requise pour PlumePg.

À noter aussi qu'en l'état rien n'interdit d'installer PlumePg et de ne pas se servir de tout ce qui a trait aux modèles.

[thiegaillard]

Bonjour, c'est l'absence d'OID pour les vues qui fait que ce n'est implémenté que pour les tables ?

[alhyss]

Bonjour @thiegaillard

Non, pour PostgreSQL les vues sont des relations au même titre que les tables, elles ont également des identifiants, qui correspondent à la valeur du champ oid de la table système pg_class pour la vue considérée. Tu l'auras aussi avec SELECT 'nom_schema.nom_vue'::regclass::oid.

Si je n'ai pas implémenté le suivi des dates de dernière modification pour les vues, c'est parce que je trouve que c'est une usine à gaz.

Le principal problème est que suivre les modifications des données présentées par une vue relève de l'impossible.

Au mieux, on pourrait faire en sorte que toute modification d'une table mette à jour en cascade la date de dernière modification des vues qui dépendent de cette table, puis des vues qui dépendent de ces vues, etc. Mais c'est un système extrêmement imparfait. En premier lieu, ce n'est pas parce qu'on a modifié un enregistrement quelque part dans une des tables sources que la vue a nécessairement changé. La requête de la vue n'appelle peut-être pas les lignes ou les colonnes concernées par les changements, par exemple. En second lieu, les valeurs présentées par la vue peuvent changer sans qu'il y ait la moindre modification sur les tables sources. C'est a priori moins fréquent, mais cela peut arriver si la requête de la vue fait appel à une fonction dont la définition viendrait à changer, par exemple. Tu as même des vues qui changent sans la moindre intervention par ailleurs. Imagine par exemple une table qui répertorie des dossiers en cours d'instruction, avec un champ de date de dépôt, et une vue qui lui ajoute une colonne indiquant le nombre de jours restant avant décision tacite, soit (en supposant que le délai d'instruction est de 2 mois) date_depot + '2 months'::interval - now()::date. Le contenu d'une telle vue sera différent d'un jour à l'autre, sans qu'aucun déclencheur ne puisse détecter quoi que ce soit.

Bref ce que montre une vue est par définition volatile, lui donner une date de dernière modification n'a pas tellement de sens à mon avis.

Dans une moindre mesure, il y a le sujet des CREATE OR REPLACE VIEW sur des vues existantes, qu'il est techniquement impossible de distinguer de la création d'une nouvelle vue. On pourra seulement présumer qu'il s'agit d'une vraie création lorsqu'il n'y a pas encore de ligne pour la vue dans la table où sont enregistrées les dates. Mais le cas d'une vue créée avant l'activation du déclencheur sur évènement plume_stamp_table_creation dont on modifierait ensuite la définition avec une commande CREATE OR REPLACE échapperait à cette règle. Même suivre les dates de création ne serait donc pas si simple.

In fine, le mieux que l'on pourrait faire de manière fiable serait :

• une date de création correspondant à la date de la création de la vue ou de sa première redéfinition post activation de plume_stamp_table_creation (CREATE OR REPLACE VIEW) ;
• une date de modification correspondant à la date de la dernière commande ALTER VIEW ou CREATE OR REPLACE VIEW pour une vue déjà référencée dans z_plume.stamp_timestamp.

J'ai considéré que ça ne présentait aucun intérêt, et que ce serait même trompeur pour des utilisateurs peu familiers des vues PostgreSQL. Ils liraient la fiche de métadonnées et verraient des dates très anciennes alors que les données source ont pu être actualisées très récemment.

Est-ce que tu vois les choses autrement ?

[thiegaillard]

Bonjour, en effet, rechercher la modification des données pour une vue est une usine à gaz et n'a pas vraiment de sens. Par contre, voir qu'une vue (matérialisée ou pas) à changer sur sa définition aurait pour moi une valeur importante Le REPLACE VIEW ne me pose pas pas de problème car savoir que c'est un nouvel élément me suffit. Je compte me servir de cela pour savoir si un schéma doit être sauvegardé ou pas.

Donc en conclusion, je suis en accord avec toi !

[alhyss]

La création d'une extension spécifique pour l'enregistrement des dates a été débattue au cours du sous-groupe Métadonnées du 12 main 2022. Vote : 3 voix pour, 3 voix contre, 3 abstentions. Le sujet sera réexaminé par l'équipe de développement, qui retiendra la solution la plus simple à mettre en oeuvre.

Le sous-groupe Métadonnées du 13 juin 2022 prend acte de la diffusion d'une version 0.1.0 de PlumePg intégrant les fonctionnalités d'enregistrement des dates.

Concernant l'enregistrement des dates relatives aux vues, le sous-groupe Métadonnées du 13 juin 2022 décide de proposer cette fonctionnalité, mais avec un déclencheur sur évènements distinct de ceux des tables, pour permettre aux administrateurs de choisir indépendamment pour les tables et les vues si les dates doivent être enregistrées ou non. Par ailleurs, afin de ne pas induire en erreur les personnes qui consultent les métadonnées avec des dates de dernière modification qui ne rendraient pas compte de la fraîcheur des données exposées par la vue, les commandes CREATE OR REPLACE VIEW (y compris sur des vues préexistantes) et ALTER VIEW mettront à jour la date de création et non la date de dernière modification, qui restera non renseignée pour les vues.

[thiegaillard]

Bonjour, je note que les déclencheurs fonctionnent bien sur la création, la modification, la suppression des tables mais pas quand le commentaire d'une table (ou d'une de ses colonnes) est modifié.