Le portail francophone de la géomatique

Hello tout le monde (ça faisait longtemps que je n'étais pas passé ici)

PostgreSQL a un des moteur d'accès concurrentiel les plus solides du monde en effet.

QGIS, en lecture seule, n'a aucun cache pour PG et relis la donnée source à chaque action de zoom ou d'interrogation. On voit donc la toute dernière version des données en permanence, et les éditions "commitées" (sauvegardées) par les autres utilisateurs, en live.

En édition classique QGIS va ouvrir une transaction de lecture seule pour remplir son cache d'édition (editBuffer) pour les objets en cours de modification coté client, et son cache d'accrochage (snapping) sur la zone .

Cela ne pose aucun verrou coté postgres, c'est volontaire car c'est le cas majoritaire de la saisie multi-utilisateurs. Donc un utilisateur qui démarre une session d'édition locale  garde une version de sa donnée sur son poste, et l'écrira sur la base au moment d'appuyer sur le bouton "enregistrer". Le dernier a raison.

Il serait possible de faire évoluer QGIS pour permettre de choisir le type de verrou à poser coté postgreSQL, mais il faut alors passer à une logique de création de transactions longues, ce qui peut être assez lourd à gérer coté base pour les administrateurs de la base.

La bonne nouvelle, c'est que ça existe déjà partiellement !

Il s'agit du mode d'édition dit "par groupe de transaction" qui s'applique sur un projet QGIS (voir menu projet / propriétés).

Le principe est d'ouvrir une transaction longue, unique pour toutes les couches partageant la même chaîne de connexion (hôte + port + mode de connexion, etc..) et d'évaluer les modifications en les envoyant directement dans la base, et non plus dans le cache d'édition coté client QGIS.  En bref, QGIS ouvre une transaction avec "BEGIN" , puis envoie tous les UPDATE / INSERT / DELETE dans cette transaction.
Les éditions sont sauvegardées sous forme de SAVEPOINT afin de pouvoir faire des annuler (CTRL+Z)/refaire quand même.

Le bénéfice génial de ce mode, est que les triggers d'édition qui peuvent porter de la logique métier (calcul auto de valeurs, contrainte topologique et accrochage d'un réseau, etc..) sont évalués et permettent de faire des application métier bien plus légères coté QGIS.

Des verrous postgres sont posés sur les objets en cours de modification, et cela implique qu'un autre client qui voudrait écrire sur ces objets, avant la fin de la transaction longue, va juste... attendre. Avec l'impression que QGIS est "freezé", jusqu'au timeout de la transaction.

Autre problème, un utilisateur qui fait une transaction longue, mais ne sauvegarde pas, va progressivement geler l'ensemble des objets qu'il a modifié pour les autres. Donc c'est dangereux et nécessite des routines pour détruire les transactions trop longues. Avec le risque de perte réelle de données.

Un de mes rêves serait que QGIS ne soit pas silencieux vis à vis des verrous posés sur les données:
- en affichant en mode édition, une infobulle sur les objets actuellements verrouillés, avec des informations sur la session et la transaction en cause (id user, application_name, etc..)
- en autorisant l'utilisateur à abandonner une tentative de sauvegarde freezée
- en exploitant les canaux NOTIFY pour envoyer un message aux utilisateurs en édition pour monter une demande de libération de la transaction.  (sisi c'est possible !! , et pas si complexe)

En revanche, aller plus loin en proposant un modèle de workflow métier en clarifiant si des personnes sont prioritaires par rapport à d'autres, par exemple, ça rentre là dans le cas d'une application métier à clarifier.

Et à ce stade, on est presque sur les platebandes de l'édition collaborative type branches / versions / code source qu'on trouve dans pas mal de plugin et des outils tous neuf comme Kart. On parle là d'avoir des branches de données parallèles et d'offrir des outils de réconciliation. C'est une tout autre histoire à dérouler dans un autre thread.

Dans tous les cas, si il y a un enjeu de risque d'écrasement de données, je ne saurais que trop conseiller de mettre en place un "audit log", c'est à dire une historisation des éditions sur les couches de données à enjeux (certains appellent cela du versionning). Un très chouette plugin https://github.com/qwat/pg-history-viewer permet de visualiser des audit de type hstore/trigger   visualiser des diff de géométrie et attributs, et restaurer des versions antérieures.

Il existe des logiques d'historisation jsonb plus modernes, mais tout ça fonctionne!  (Attention à ne pas indexer ces historiques sinon ce sera lent, et pour les couches à forte dynamique de saisie, penser à purger l'historique pour ne pas saturer la base )


Régis

Merci pour la réponse très complète.

Je ne vois pas ça dans mon QGIS 3.16.

Coool !

On met ça de côté. Faudrait trouver du temps pour évaluer Kart aussi...