Problem z przyciąganiem w edytowanych widokach POSTGIS

[xmaziax]

Problem wygląda następująco.

Mam zbudowaną tabelę w bazie danych Postgresql.
Na niej  zbudowałem widok, na widoku trigger + funkcję dla niego odpowiedzialne za edycję danych (insert/update/delete).

Edycja danych w widoku działa prawidłowo, wszystkie operacje wykonują się poprawnie.
Jest natomiast problem ze snapowaniem dla nowo powstałych elementów (nowo narysowanych lub tych  powstałych przez podział już istniejących).
Nie działa dla nich przyciąganie.

Po ponownym odczycie widoku, można już się snapować do tych obiektów.
Można "uwidocznić" obiekt dla przyciągania, gdy się go "poruszy" narzędziem do modyfikacji vertexów - wtedy obiekt staje się "snapowalny"

Znalazłem podobny wątek ze zgłoszonym błędem dla tabeli Oracle'a edytowanej w QGis.
https://issues.qgis.org/issues/12690
Sprawdziłem i przy bezpośredniej edycji tabeli Postgis, problem się nie pojawia - czyli to wina operacji na widokach.l

Coś robię nie tak czy problem leży raczej po stronie QGis i należy zgłaszać błąd twórcom?
Ktoś coś doradzi? 

Używam QGis 2.18.17, Postgresql 9.6, Postgis 2.3.3

Poniżej kod umożliwiający odtworzenie sytuacji.

Kod:

CREATE SEQUENCE public.testw_id_seq
 INCREMENT 1
 MINVALUE 1
 MAXVALUE 9223372036854775807
 START 1
 CACHE 1;

CREATE TABLE public.testw
(
 id integer NOT NULL DEFAULT nextval('testw_id_seq'::regclass),
 atr1 integer DEFAULT 1,
 atr2 integer,
 geom geometry(Polygon,2177),
 CONSTRAINT testw_pkey PRIMARY KEY (id)
);
CREATE INDEX testw_geom_idx1  ON public.testw  USING gist  (geom);

CREATE OR REPLACE FUNCTION public.v_test_mod()
 RETURNS trigger AS
$BODY$
DECLARE    
    val integer;
BEGIN
IF TG_OP = 'INSERT' THEN
    val = nextval('testw_id_seq');    
    insert into testw  (id, atr1, atr2, geom )
    VALUES
    (val,  1,  NEW.atr2, NEW.geom);
    RETURN NEW;    
ELSIF TG_OP = 'UPDATE' THEN
    update  testw  set  geom = NEW.geom, atr1 = NEW.atr1, atr2 = NEW.atr2  where id = OLD.id;
    RETURN NEW;
ELSIF TG_OP = 'DELETE' THEN
    delete from  testw where id =OLD.id;
    RETURN NULL;
END IF;
   RETURN NEW;
END;
$BODY$
 LANGUAGE plpgsql VOLATILE SECURITY DEFINER
 COST 100;
 

CREATE TRIGGER v_testw_1_tr
 INSTEAD OF INSERT OR UPDATE OR DELETE
 ON public.v_testw_1
 FOR EACH ROW
 EXECUTE PROCEDURE public.v_test_mod();

[xmaziax]

W treści poprzedniego posta zabrakło kodu budującego widok
Należy go odpalić przed budowa triggera

[xmaziax]

Nie mogę edytować ani usuwać swoich postów - stąd kolejne 2 posty.

Kod:

CREATE OR REPLACE VIEW public.v_testw_1 AS
SELECT testw.id,
   testw.atr1,
   testw.atr2,
   testw.geom
  FROM testw
 WHERE testw.atr1 = 1;

[andrus]

Na postgresie się nie znam ale na innych silnikach sql trochę tak. Może intuicyjnie trafię
Zmodyfikuj kod trigera.

Zamiast:
val = nextval('testw_id_seq');
insert into testw (id, atr1, atr2, geom )
VALUES (val, 1, NEW.atr2, NEW.geom);

Zakoduj tak:
insert into testw (atr1, atr2, geom )
VALUES (1, NEW.atr2, NEW.geom);

Na kolumnie id masz default sekwencyjny - nie wiem czy przypadkiem postgres nie rezerwuje sobie sekwencji przed wywołaniem trigera.

[xmaziax]

Dzięki za sugestię, ale to raczej nie jest wina funkcji triggera.

Przy insercie muszę wygenerować nowe id, bo ja działam na widokach.
W przykładzie, widok założony jest na jednej tabeli, ale nieraz używam widoków na kilku tabelach i w przypadku zmian muszę oprogramować aktualizację w nich wszystkich.
Dla tabeli z założoną wartością domyślną, sekwencją i PK (nie sprawdzałem czy wszystkie 3 wymienione są wymagane) nie ma potrzeby generowania id z poziomu triggera.

Sprawdziłem te dane w QGis3 i tam nie ma tego problemu (ale są inne ) 
Niestety jest jeszcze za wcześnie na migrację do 3.

[andrus]

Pole id w tabeli (rzeczywistej) testw masz zadeklarowane w ten sposób :
id integer NOT NULL DEFAULT nextval('testw_id_seq'::regclass),
a więc w momencie insertu który nie specyfikuje wartości id (insert into testw (atr1, atr2, geom ) ...) wstawiany będzie default czyli kolejny numer z sekwencji, nie ma zupełnie potrzeby pobierać wartości sekwencji w trigerze. Ale nie znam się na Postgresie i jest tu jakiś niuans.

[andrus]

Dodam jeszcze że piszesz że problem jest tylko w momencie wstawiania nowego elementu (przy edycji jest ok). Czym się różni update od insertu w kodzie tego trigera - właśnie tą sekwencją. W zalinkowanym przez Ciebie podobnym błędzie też przyczyną była sekwencja. Sugeruję że warto sprawdzić może to jest to.

[xmaziax]

Sprawdzałem to już wcześniej - nie działa, ale dzięki za sugestie.

Tak, problem jest przy wstawianiu nowego obiektu z poziomu widoku.
Do momentu zapisu tego elementu - przyciąganie dla niego działa (to jest chyba tymczasowa geometria, a nie fizycznie obiekt w bazie).
Po wciśnięciu przycisku zapisz (nawet bez kończenia edycji warstwy) - już nie można się do niego dosnapować.
Jest dokładnie tak jak ktoś opisał we wstawionym przeze mnie linku, ale dotyczyło to tabeli Oracle'a.
Zresztą z tego co widziałem, ten powyższy błąd wymagał jednak zmian w kodzie QGis'a, więc to problem raczej po stronie QGis.

Żeby na warstwie widoku element był snapowalny, musi być już na warstwie w chwili podpięcia do Qgis'a lub musi być zmieniona jego geometria.
Wystarczy zmodyfikować jeden vertex, przesunąć obiekt, a do tego snap nie jest potrzebny. 
Po takim zabiegu przyciąganie działa.

[xmaziax]

Jak by kogoś to interesowało to w wersji 2.18.18 błąd został wyeliminowany.