Actualisation de la date de dernière modification lorsque le descriptif de la table ou d'un champ est modifié

@thiegaillard J'ouvre une nouvelle issue parce qu'il y a potentiellement matière à discussion.

Effectivement, les commandes COMMENT ne sont actuellement pas prises en compte.

Sur le principe, il me semble normal qu'elles n'affectent pas la date dernière modification des données, car les descriptifs des tables et des champs relèvent à mon sens des métadonnées plutôt que des données. Or Plume distingue bien la date de dernière modification des données (dont la mise à jour est gérée par les déclencheurs en question) de la date de dernière modification des métadonnées (dont la mise à jour est actuellement gérée uniquement par le plugin QGIS, puisqu'il est supposé être le seul outil d'édition des métadonnées).

Pour les commandes COMMENT ON TABLE, c'est aussi une précaution. L'activation du déclencheur stamp_timestamp_to_metadata sur z_plume.stamp_timestamp permet l'enregistrement automatique des dates de z_plume.stamp_timestamp dans les métadonnées, ce qui implique donc d'éditer le descriptif de la table. Si ces commandes COMMENT déclenchaient elles-mêmes plume_stamp_table_modification, cela créerait une boucle infinie.

Ceci étant dit, on pourrait imaginer ajouter à la table z_plume.stamp_timestamp un champ metadata pour la date de dernière modification des métadonnées, qui serait mise à jour par un déclencheur sur l'évènement COMMENT portant sur des tables ou champs de tables. Cette date-là ne pourrait pas être enregistrée automatiquement dans les métadonnées (non considérée par stamp_timestamp_to_metadata, qui resterait inchangé), afin d'éviter les boucles infinies.

Je dois dire toutefois que je ne vois pas bien l'intérêt d'une telle date du point de vue de la gestion des métadonnées. La date de dernière modification des métadonnées est déjà systématiquement mise à jour par le plugin QGIS, le seul bénéfice de metadata serait de prendre aussi en compte les modifications réalisées hors plugin... C'est sans doute marginal, et d'ailleurs pas forcément une bonne chose pour les utilisateurs si ce qui est modifié dans le descriptif de la table se trouve hors des balises <METADATA>. Il vaudrait peut-être mieux qu'une telle date ne remonte jamais dans les métadonnées.

Au fond, la question est de savoir si nous voulons que ce système de gestion des dates puisse servir pour les sauvegardes et autres opérations de maintenance sans rapport direct avec la documentation des données, ou si cette dernière finalité doit rester notre seule cible. Dans l'hypothèse où le champ metadata susmentionné conviendrait à tes besoins, je pense préférable de soumettre cette question au sous-groupe Métadonnées.

MTES-MCT / metadata-postgresql

Actualisation de la date de dernière modification lorsque le descriptif de la table ou d'un champ est modifié #92