Buongiorno lista,
volevo capire se il comportamento di QGIS descritto di seguito è corretto oppure se, come ritengo, possa trattarsi di bug.
Lavoro con tabelle PostgreSQL. Ho testato su QGIS 2.18 e 3.4
In pratica fondendo due linee di tipo LINESTRING che hanno un nodo in comune la catena di lavoro che risulta è:
BEGIN;
DELETE delle 2 linee
COMMIT;
BEGIN;
INSERT della nuova linea fusa.
COMMIT;
Se un campo alfanumerico della tabella della nuova linea unita non soddisfa condizioni imposte si genera un errore ma DOPO che il primo COMMIT è andato a buon fine. Nel caso in cui decida di non salvare le modifiche e chiudere l’editing le due linee risultano comunque eliminate. Quindi nonostante apparentemente non abbia fatto nessuna modifica (ho fatto start editing, mi ha dato errore, ho chiuso l’editing senza salvare) in realtà la mia tabella è cambiata (e non poco!).
Concettualmente mi parrebbe più opportuno:
BEGIN;
DELETE delle 2 linee
INSERT della nuova linea fusa.
COMMIT;
Se invece si riesce a sanare l’errore la fusione avviene con successo.
Di seguito una estrema semplificazione per riprodurre quanto sopra. In QGIS una volta in editing, selezionate le due linee, e usato “Fondi gli elementi selezionati” mettere un valore di b maggiore di a in “Fondi Attributi Elemento” e salvare.
Si genera l’errore "
Impossibile applicare le modifiche al vettore pippo
Errori: SUCCESSO: 2 elementi eliminati.
ERRORE: 1 geometria non aggiunta.
Errori della sorgente dati:
Errore PostGIS nell’aggiunta delle geometrie: ERRORE: pippo
CONTEXT: funzione PL/pgSQL pippo_elimina() riga 6 a RAISE
"
Quindi abbandonare le modifiche senza salvare
CREATE TABLE
pippo (
gid serial PRIMARY KEY,
a int,
b int,
geom geometry(LINESTRING, 3003)
)
;
CREATE OR REPLACE FUNCTION pippo_elimina()
RETURNS trigger
LANGUAGE plpgsql
AS $function$
BEGIN
IF NEW.a < NEW.b THEN
RAISE EXCEPTION ‘pippo’;
ELSE
RETURN NEW;
END IF;
END; $function$
;
CREATE TRIGGER
pippo_before_insup
BEFORE INSERT OR UPDATE ON
pippo
FOR EACH ROW EXECUTE PROCEDURE
pippo_elimina()
;
INSERT INTO
pippo (a,b,geom)
VALUES
(10,5,‘0102000020BB0B000003000000BFD7DF8507B039419768526EEF8E5241659D8450C7B2394154EC9CFCB58E52412B15FD791CB33941C40B94587D8E5241’),
(15,12, ‘0102000020BB0B0000030000002B15FD791CB33941C40B94587D8E524185769A7466B639414213C1391D8F524169A67ACC3EB53941AB3EB0AB9A8E5241’)
;