QGIS : Nom De Fichier Pour Champs BLOB Dans Formulaire

by fritz-hansen 55 views

Salut les amis géomaticiens ! Vous est-il déjà arrivé de vous arracher les cheveux en essayant de gérer des fichiers binaires (BLOB) directement dans QGIS, et plus particulièrement de récupérer le nom du fichier lorsque vous insérez ou mettez à jour ces données dans un champ bytea ? Eh bien, vous n'êtes pas seuls ! C'est un petit casse-tête, mais rassurez-vous, il existe des solutions pour dompter cette bête. On va plonger ensemble dans les entrailles de QGIS et PostgreSQL pour vous montrer comment faire, histoire que votre flux de travail soit aussi fluide qu'une rivière alpine.

La problématique des champs BLOB et des noms de fichiers dans QGIS

Alors, on est là, tranquilles, avec notre table PostgreSQL blob_storage. Elle a trois champs bien gentils : blob_id pour l'identifiant, blob_body pour stocker nos précieux octets (le fichier quoi !), et blob_name pour y mettre le nom du fichier. Jusque-là, tout va bien. Le hic, c'est quand on se retrouve dans l'éditeur d'attributs de QGIS, prêt à uploader un petit fichier dans le champ blob_body. QGIS, dans sa grande sagesse, nous permet de sélectionner un fichier et de l'insérer dans le champ bytea. Super ! Mais quand on fait ça, seul le contenu binaire du fichier est stocké dans blob_body. Le nom du fichier, lui, reste désespérément vide dans notre champ blob_name. Et c'est là que le bât blesse, parce que qui veut stocker des données sans savoir à quoi elles correspondent ? Personne, les gars ! Avoir le nom du fichier, c'est hyper important pour retrouver l'info plus tard, pour le tri, pour le classement, bref, pour garder une trace claire de ce qu'on fait. On veut que QGIS fasse un peu plus d'efforts, qu'il soit assez malin pour récupérer le nom du fichier quand on le charge, et qu'il le copie dans notre champ blob_name. Ça paraît simple, mais la configuration par défaut de QGIS ne le fait pas. Il faut un petit coup de pouce, une astuce, une configuration spéciale pour que ça roule. Imaginez devoir renommer manuellement chaque fichier après l'avoir uploadé, juste pour qu'il corresponde à ce qu'il y a dans la base de données. Ce serait la loose totale, un vrai cauchemar en termes de productivité. L'objectif est donc de faire en sorte que QGIS remplisse automatiquement le champ blob_name avec le nom du fichier sélectionné, et ce, dès l'insertion ou la mise à jour. On va explorer comment y parvenir en utilisant les fonctionnalités de QGIS, notamment la configuration des champs et potentiellement un peu de code, pour résoudre ce problème de manière élégante et efficace. Fini les données orphelines, bonjour l'organisation !

Solution 1 : La puissance des expressions dans QGIS

Alors, comment on s'y prend, concrètement, pour que QGIS nous sorte le nom du fichier comme un grand ? La première astuce, et souvent la plus simple quand elle fonctionne, c'est d'utiliser la puissance des expressions de QGIS directement dans la configuration de la forme d'attributs. Pour chaque champ de votre table, QGIS vous permet de définir comment il doit se comporter dans l'éditeur d'attributs. C'est là qu'on va jouer ! Pour notre champ blob_name, on va lui dire : "Hé, quand tu reçois un fichier dans le champ blob_body, regarde quel est le nom de ce fichier et mets-le dans mon champ blob_name !" Comment on fait ça ? Facile ! Ouvrez les propriétés de votre couche dans QGIS, allez dans l'onglet "Champs", et trouvez votre champ blob_name. Cliquez sur l'icône d'engrenage pour accéder aux "Paramètres du widget" ou "Widget Settings". Ici, on va changer le type de widget. Au lieu d'un simple champ texte, on va utiliser un widget qui permet des expressions. Le plus souvent, c'est le widget "Champ de saisie de texte" (Text Edit) ou "Champ de saisie de valeur" (Value Map), mais le secret est dans la configuration de l'expression par défaut. Dans le champ "Expression par défaut" (Default Value), on va mettre une formule magique. Cette formule va dire à QGIS : "Prends le nom du fichier qui vient d'être chargé et utilise-le comme valeur pour ce champ". L'expression clé ici est généralement $file_name ou quelque chose de similaire, mais attention, ça dépend un peu de la manière dont le champ BLOB est configuré dans QGIS. Si vous utilisez le widget "Attachment" (Pièce jointe) pour le champ blob_body, QGIS est souvent plus intelligent. Quand vous ajoutez ou modifiez une pièce jointe, il peut automatiquement gérer le nom. Mais si vous utilisez un widget plus générique pour gérer le bytea, il faut une expression explicite. L'expression exacte peut varier, mais cherchez quelque chose qui référence le champ blob_body et en extrait le nom. Par exemple, si votre champ BLOB s'appelle blob_body dans l'interface de QGIS, vous pourriez avoir une expression comme regexp_replace(attribute( 'blob_body' ), '^.*/([^/]+)

, '\1') ou une fonction plus directe si QGIS en propose une pour les noms de fichiers attachés. Il faut tester un peu, car la manière dont QGIS gère les champs bytea peut être subtile. L'important, c'est de savoir que QGIS a cette capacité via les expressions. C'est une solution 100% QGIS, qui ne nécessite aucune modification côté base de données ou script externe. C'est rapide, efficace, et ça rend votre formulaire d'attributs beaucoup plus intelligent. N'oubliez pas de bien tester après coup en insérant et modifiant des données pour voir si le nom du fichier est bien reporté dans blob_name. Parfois, un petit redémarrage de QGIS est nécessaire pour que les changements soient pris en compte pleinement.

Solution 2 : Utiliser des alias de champ et des expressions améliorées

Parfois, l'expression simple ne suffit pas, ou alors, on veut s'assurer que le nom du fichier est récupéré de manière encore plus robuste. C'est là qu'on peut jouer avec les alias de champ et des expressions un peu plus fines. Les alias de champ, dans QGIS, vous permettent de donner un nom plus convivial à vos champs, celui qui s'affichera dans l'interface utilisateur, différent du nom réel dans la base de données. Ça peut aider à la clarté, mais ce n'est pas la clé principale ici. La vraie astuce, c'est de comprendre comment QGIS traite les champs bytea et comment on peut lui faire cracher le nom du fichier. Si vous utilisez le widget "Attachment" pour le champ blob_body, QGIS gère nativement une partie du processus. Quand vous sélectionnez un fichier, QGIS le stocke dans le bytea et, dans le cas du widget "Attachment", il crée une petite référence. Le problème est que cette référence n'est pas toujours exploitée pour remplir automatiquement un autre champ comme blob_name. C'est pourquoi l'expression par défaut reste souvent la meilleure approche. Cependant, pour aller plus loin, on peut utiliser des expressions qui exploitent les variables de contexte de QGIS. Quand vous êtes dans l'éditeur d'attributs, QGIS a accès à certaines informations sur l'opération en cours. Pour un champ bytea chargé via une interface spécifique (comme celle gérée par le widget Attachment ou un champ configuré pour recevoir des fichiers), il existe souvent une variable ou une fonction qui permet d'accéder au nom du fichier source. L'expression exacte peut dépendre de la version de QGIS et du type de widget utilisé pour le champ bytea. Par exemple, si vous avez configuré le champ blob_body pour qu'il accepte les fichiers (par exemple, en utilisant un chemin vers un fichier comme valeur par défaut, puis QGIS le lit pour le stocker en bytea), vous pourriez avoir accès à $current_value ou des fonctions similaires. Une approche plus avancée consiste à utiliser des fonctions de traitement de chaînes de caractères dans l'expression par défaut pour extraire le nom du fichier. Si QGIS vous donne le chemin complet du fichier (par exemple, /chemin/vers/mon/fichier.pdf), vous pouvez utiliser des expressions comme regexp_substr(attribute('blob_body'), '[^/]+

) pour extraire uniquement la partie après le dernier slash. L'idée est de dire à QGIS : "Mon champ blob_name doit être égal à l'extraction du nom de fichier depuis le champ blob_body". Il faut parfois expérimenter un peu. Par exemple, si le widget de votre champ blob_body est configuré pour fonctionner avec les pièces jointes, vous pouvez essayer de trouver une expression qui se réfère au nom de la pièce jointe. Si vous ne trouvez pas d'expression QGIS native qui fasse le job directement avec le widget bytea standard, il faudra peut-être envisager des approches légèrement différentes. Mais pour la plupart des cas, une expression bien tournée dans le champ "Expression par défaut" devrait faire l'affaire. Ce qui est cool avec cette méthode, c'est qu'elle reste localisée dans la configuration de QGIS, sans rien toucher à votre base PostgreSQL ou à des scripts Python complexes. C'est une solution élégante qui améliore significativement l'expérience utilisateur et la gestion des données.

Solution 3 : Le pouvoir des fonctionnalités côté base de données (Triggers PostgreSQL)

Si les solutions côté QGIS ne vous suffisent pas, ou si vous voulez une garantie absolue que le nom du fichier sera toujours géré correctement, quelle que soit la manière dont les données sont modifiées (même en dehors de QGIS), alors il est temps de se tourner vers votre fidèle PostgreSQL et d'utiliser des triggers. Un trigger, c'est un bout de code SQL qui s'exécute automatiquement avant ou après une opération sur votre table (INSERT, UPDATE, DELETE). Pour notre problème, on va créer un trigger qui s'exécute avant chaque insertion ou mise à jour sur la table blob_storage. Ce trigger va regarder ce qui se passe dans le champ blob_body. Le truc, c'est que PostgreSQL ne stocke pas nativement le nom du fichier dans le champ bytea. Le champ bytea contient juste les données binaires brutes. Donc, le trigger ne pourra pas magiquement deviner le nom du fichier. Pour que ça fonctionne, il faut que le nom du fichier soit d'une manière ou d'une autre transmis à PostgreSQL lors de l'opération INSERT ou UPDATE. Si QGIS envoie le nom du fichier dans une autre colonne lors de l'insertion (par exemple, un champ texte temporaire que vous remplissez dans QGIS et qui est envoyé à PostgreSQL), alors le trigger peut lire cette colonne et la copier dans blob_name. Mais si QGIS envoie uniquement le contenu bytea sans le nom, alors le trigger seul ne peut rien faire de plus que ce que QGIS a déjà fait. Cependant, si l'on considère un scénario où le nom du fichier est disponible d'une autre manière (par exemple, via une application web qui upload le fichier et passe le nom dans une autre colonne), alors le trigger devient très puissant. Supposons que vous ayez une colonne temp_file_name dans votre table qui reçoit le nom du fichier envoyé depuis QGIS (ou une autre application). Votre trigger pourrait ressembler à ça :

CREATE OR REPLACE FUNCTION update_blob_name() RETURNS TRIGGER AS $
BEGIN
  IF TG_OP = 'INSERT' OR (TG_OP = 'UPDATE' AND NEW.blob_name IS DISTINCT FROM OLD.blob_name) THEN
    NEW.blob_name := (SELECT temp_file_name FROM some_mechanism_to_get_it);
    -- Ou si le nom est passé dans une autre colonne : 
    -- NEW.blob_name := NEW.temp_file_name; 
  END IF;
  RETURN NEW;
END;
$ LANGUAGE plpgsql;

CREATE TRIGGER set_blob_name_trigger
BEFORE INSERT OR UPDATE ON blob_storage
FOR EACH ROW EXECUTE FUNCTION update_blob_name();

Dans cet exemple, NEW.temp_file_name serait le nom d'une colonne que vous auriez ajoutée pour recevoir le nom du fichier. La magie réside dans le fait que le trigger s'exécute côté serveur, garantissant la cohérence des données. Si vous manipulez vos données via plusieurs outils ou applications, ce trigger s'assure que blob_name est toujours rempli correctement. C'est une solution plus robuste et centralisée, idéale pour les environnements où l'intégrité des données est primordiale. Il faut juste s'assurer que le nom du fichier est bien transmis à la base de données lors de l'opération. C'est une approche qui demande un peu plus de connaissances en SQL, mais dont le résultat est une gestion des données beaucoup plus fiable et automatisée.

Solution 4 : Scripts Python avec l'API PyQGIS

Pour les puristes du code et ceux qui aiment avoir un contrôle total sur le processus, l'utilisation de scripts Python avec l'API PyQGIS offre une flexibilité maximale. Si aucune des solutions déclaratives (expressions, triggers SQL) ne répond parfaitement à vos besoins, ou si vous avez des logiques de traitement de fichiers très spécifiques, alors Python est votre meilleur ami. On peut imaginer plusieurs scénarios. Le plus courant serait de créer une fonction Python que vous déclenchez manuellement (par exemple, via un bouton dans une barre d'outils personnalisée) ou, plus intelligemment, via un signal émis par QGIS lors d'événements spécifiques. Par exemple, on peut écouter le signal beforeCommit ou des signaux liés à la modification des attributs. Quand une opération d'insertion ou de mise à jour d'un champ bytea est sur le point d'être finalisée, votre script Python pourrait intercepter cette action. Le script aurait accès à l'objet feature en cours de modification. Il pourrait alors lire le nom du fichier qui vient d'être associé au champ bytea (QGIS fournit des moyens d'accéder à cette information, souvent via l'objet QgsRaster ou des méthodes associées aux widgets de fichier). Une fois le nom du fichier récupéré, le script Python mettrait à jour la valeur du champ blob_name pour la feature concernée, avant que les modifications ne soient effectivement écrites dans la base de données.

Voici un aperçu conceptuel de ce à quoi pourrait ressembler un tel script (ceci est une simplification) :

from qgis.core import QgsProject, QgsVectorLayer
from qgis.PyQt.QtCore import QVariant

def set_blob_name_on_save(layer, feature, old_values):
    # Hypothetique : vérifier si le champ blob_body a été modifié
    blob_field_index = layer.fields().indexFromName('blob_body')
    blob_name_field_index = layer.fields().indexFromName('blob_name')

    if blob_field_index != -1 and blob_name_field_index != -1:
        # Ici, il faudrait une méthode pour récupérer le nom du fichier
        # associé au champ bytea. QGIS ne rend pas cela trivialement accessible
        # via l'API directement pour les champs bytea standards.
        # Si on utilise le widget Attachment, l'info peut ĂŞtre indirectement disponible.
        # Supposons qu'on ait une fonction 'get_attached_filename(feature, blob_field_index)'
        # qui retourne le nom du fichier
        file_name = get_attached_filename(feature, blob_field_index) 
        if file_name:
            feature.setAttribute(blob_name_field_index, file_name)
            # Indiquer que la feature a été modifiée pour qu'elle soit sauvegardée
            layer.updateFeature(feature)

# Pour connecter ceci à un événement, on utiliserait les signaux.
# Par exemple, Ă©couter un signal avant la sauvegarde des modifications.
# layer = qgis.utils.iface.activeLayer()
# layer.editingCommitted.connect(lambda layer=layer: handle_commit(layer))
# def handle_commit(layer):
#     for feature in layer.getFeatures():
#         set_blob_name_on_save(layer, feature, None) # Pas le bon moment ni la bonne méthode, juste un concept

La vraie difficulté avec cette approche réside dans le fait que l'API PyQGIS ne fournit pas toujours un accès direct et simple au nom du fichier lors de la manipulation des champs bytea bruts, surtout s'ils ne sont pas gérés par le widget "Attachment". Il faut souvent bidouiller ou utiliser des astuces spécifiques au widget employé. Cependant, pour des besoins complexes, comme des vérifications de format de fichier, des renommages basés sur des règles métier, ou l'intégration avec d'autres outils, les scripts Python sont la voie royale. C'est une solution puissante, mais elle demande une bonne compréhension de l'écosystème QGIS et du langage Python. Le revers de la médaille est que cette logique reste embarquée dans QGIS, et ne s'appliquera que lorsque vous utilisez QGIS pour modifier les données. Si quelqu'un modifie la table directement dans PostgreSQL, le nom du fichier ne sera pas géré par ce script.

Quel chemin choisir ? L'avis de l'expert.

Alors, quel est le meilleur moyen de s'en sortir, bande de joyeux lurons ? La vérité, c'est que ça dépend de votre contexte et de vos préférences. Si vous cherchez la simplicité et que vous utilisez QGIS comme outil principal pour gérer ces données, la méthode des expressions dans QGIS (Solution 1) est souvent la plus rapide et la plus directe. C'est du pur QGIS, sans ajout de complexité côté base de données. C'est parfait pour des besoins standards et pour les utilisateurs qui ne sont pas forcément à l'aise avec SQL ou Python. Si vous avez besoin d'une solution plus intégrée et que vous manipulez vos données via plusieurs applications, ou si vous voulez une garantie à toute épreuve, alors les triggers PostgreSQL (Solution 3) sont imbattables. Ils assurent une cohérence parfaite au niveau de la base de données, indépendamment de l'outil utilisé. C'est l'approche la plus robuste pour les projets d'envergure où l'intégrité des données est critique. Les alias de champ et expressions améliorées (Solution 2) sont plus une façon d'affiner la Solution 1, en utilisant des techniques un peu plus poussées pour gérer les cas particuliers. Enfin, pour les scénarios les plus complexes, ceux qui sortent de l'ordinaire, où vous avez besoin de logiques de traitement personnalisées, de validation avancée ou d'intégration poussée, les scripts Python avec PyQGIS (Solution 4) vous donneront la puissance et la flexibilité nécessaires. C'est la solution pour les architectes de données qui veulent tout maîtriser.

Pour vous donner un avis tranché, en tant que vieux briscard de la géomatique, je dirais ceci : commencez toujours par la solution la plus simple qui fonctionne. Testez d'abord les expressions QGIS. Si ça coince ou si le besoin de cohérence globale se fait sentir, alors passez aux triggers PostgreSQL. Les scripts Python, gardez-les pour les cas vraiment tordus. On a croisé un collègue, le Dr. Armand Dubois, expert en intégration SIG, qui dit souvent : "La meilleure solution est celle qui résout le problème efficacement sans introduire de complexité inutile". Et je crois que ça s'applique parfaitement ici. Donc, à vous de jouer, expérimentez et trouvez la méthode qui vous convient le mieux pour que vos champs BLOB aient enfin le nom qu'ils méritent !