QGIS Server sendet UPDATE… WHERE NULL an Postgis in einer WFS-Ebene


9

Ich verwende einen Windows Server 2012-Server.

PostgreSQL 9.3.5, 64-Bit

POSTGIS 2.1.3

QGIS Server 2.6.1-2

QGIS Desktop 2.8.3 und 2.12

Ich verwende ein Microsoft Surface Pro 4-Tablet mit QGIS Desktop 2.12, um einige in der Postgresql-Datenbank gespeicherte Ebenen zu bearbeiten. Die Ebenen im Tablet sind WFS-Ebenen, die von QGIS Server bereitgestellt werden.

Wenn ich nach dem Einfügen einiger Daten in die Ebene eine Google-Bearbeitung durchführe, um das Senden und Speichern der Daten auf dem Server zu erzwingen, wird die Aktualisierung manchmal nicht in der Datenbank durchgeführt.

Ich kann sehen, dass die POST-http-Anfrage auf dem Server eintrifft, aber manchmal kann ich kein Commit (Update) in der Datenbank sehen und manchmal funktioniert es in Ordnung und führt das Commit aus.

In den Protokollen von QGIS Server kann ich Folgendes sehen (ich habe die Daten von 3 Funktionen in QGIS Desktop aktualisiert):

//QGIS SERVER RECEIVED HTTP POST FROM QGIS DESKTOP

[4852][11:11:19] ********************new request*************** [4852][11:11:19] remote ip: 192.168.144.20 [4852][11:11:19] CONTENT_TYPE: text/xml [4852][11:11:19] HTTP_USER_AGENT: Mozilla/5.0 QGIS/2.8.2-Wien [4852][11:11:19] MAP:D:\OSGeo4W\apps\qgis\bin\alumbrado\alumbrado.qgs
[4852][11:11:19] REQUEST:Transaction
[4852][11:11:19] REQUEST_BODY:<Transaction xmlns="http://www.opengis.net/wfs"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0.0"
service="WFS" xsi:schemaLocation="http://www.qgis.org/gml
http://eudala2.getxo.net/qgis/qgis_mapserv.fcgi.exe?map=D:\OSGeo4W\apps\qgis\bin\alumbrado\alumbrado.qgs&amp;SERVICE=WFS&amp;VERSION=1.0.0&amp;REQUEST=DescribeFeatureType&amp;TYPENAME=getxo_alumbrado_arquetas_registros_cajas&amp;SRSNAME=EPSG:23030"
xmlns:gml="http://www.opengis.net/gml"><Update
xmlns="http://www.opengis.net/wfs"
typeName="getxo_alumbrado_arquetas_registros_cajas"><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">id_modelo</Name><Value
xmlns="http://www.opengis.net/wfs">0</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">alumbrado</Name><Value
xmlns="http://www.opengis.net/wfs">t</Value></Property><Filter
xmlns="http://www.opengis.net/ogc"><FeatureId
xmlns="http://www.opengis.net/ogc"
fid="getxo_alumbrado_arquetas_registros_cajas.3"/></Filter></Update><Update
xmlns="http://www.opengis.net/wfs"
typeName="getxo_alumbrado_arquetas_registros_cajas"><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">id_modelo</Name><Value
xmlns="http://www.opengis.net/wfs">0</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">alumbrado</Name><Value
xmlns="http://www.opengis.net/wfs">t</Value></Property><Filter
xmlns="http://www.opengis.net/ogc"><FeatureId
xmlns="http://www.opengis.net/ogc"
fid="getxo_alumbrado_arquetas_registros_cajas.4"/></Filter></Update><Update
xmlns="http://www.opengis.net/wfs"
typeName="getxo_alumbrado_arquetas_registros_cajas"><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">tipo</Name><Value
xmlns="http://www.opengis.net/wfs">A</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">tipo_tapa</Name><Value
xmlns="http://www.opengis.net/wfs">B</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">estado</Name><Value
xmlns="http://www.opengis.net/wfs">D</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">p_tierra_tipo_electrodo_tierra</Name><Value
xmlns="http://www.opengis.net/wfs">O</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">p_tierra_tipo_union_electrodo_tierra</Name><Value
xmlns="http://www.opengis.net/wfs">N</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">p_tierra_estado_union_tierra</Name><Value
xmlns="http://www.opengis.net/wfs">D</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">tipo_intervencion</Name><Value
xmlns="http://www.opengis.net/wfs">OTR</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">m_codcalle</Name><Value
xmlns="http://www.opengis.net/wfs">20</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">id_modelo</Name><Value
xmlns="http://www.opengis.net/wfs">0</Value></Property><Property
xmlns="http://www.opengis.net/wfs"><Name
xmlns="http://www.opengis.net/wfs">alumbrado</Name><Value
xmlns="http://www.opengis.net/wfs">t</Value></Property><Filter
xmlns="http://www.opengis.net/ogc"><FeatureId
xmlns="http://www.opengis.net/ogc"
fid="getxo_alumbrado_arquetas_registros_cajas.5"/></Filter></Update></Transaction>
[4852][11:11:19] SERVICE:WFS
[4852][11:11:19] SRSNAME:EPSG:23030
[4852][11:11:19] VERSION:1.0.0
[4852][11:11:22] Request finished in 2977 ms

Ok, wenn ich in PostgreSQL-Protokolle schaue, kann ich sehen, dass das Update eine WHERE NULL-Klausel hat, die nichts aktualisiert.

//POSTGRESQL UPDATE QUERIES
2016-01-29 11:11:22 CET LOG:  00000: sentencia: UPDATE "public"."getxo_alumbrado_arquetas_registros_cajas" SET "id_modelo"=0,"alumbrado"='t' WHERE NULL
2016-01-29 11:11:22 CET UBICACIÓN:  exec_simple_query, src\backend\tcop\postgres.c:890
2016-01-29 11:11:22 CET LOG:  00000: sentencia: UPDATE "public"."getxo_alumbrado_arquetas_registros_cajas" SET "id_modelo"=0,"alumbrado"='t' WHERE NULL
2016-01-29 11:11:22 CET UBICACIÓN:  exec_simple_query, src\backend\tcop\postgres.c:890
2016-01-29 11:11:22 CET LOG:  00000: sentencia: UPDATE "public"."getxo_alumbrado_arquetas_registros_cajas" SET "tipo"='A',"tipo_tapa"='B',"estado"='D',"p_tierra_tipo_electrodo_tierra"='O',"p_tierra_tipo_union_electrodo_tierra"='N',"p_tierra_estado_union_tierra"='D',"tipo_intervencion"='OTR',"m_codcalle"='20',"id_modelo"=0,"alumbrado"='t'
WHERE NULL

Ich kann in den POST-Daten sehen, dass QGIS Server weiß, welche Funktion unter Verwendung der internen "fid" -Nummer aktualisiert werden muss. Meine Ebene hat dagegen das Feld "id" als Primärschlüssel. Irgendwo, wenn die Zuordnung von QGIS-interner FID zur ID meiner Ebene erfolgt, geht sie verloren und fügt der Abfrage WHERE null hinzu, anstatt hinzuzufügen, wobei id = 1510 ist.

Das Lustige ist, dass sie seit 40 Tagen arbeiten und dieses Problem nur einmal haben, aber seit letzter Woche haben sie dieses Problem jeden Tag ... Seitdem funktioniert es manchmal und manchmal nicht. Ich sende die POST-http-Anfrage vom Client erneut, indem ich den Fiddles-Proxy verwende, und der gleiche HTTP-Beitrag funktioniert manchmal und manchmal nicht.

Ich habe es in QGIS Desktop 2.8, 2.10 und 2.12 getestet und es kommt in allen vor (QGIS Server ist 2.6.1, glaube ich). Ich habe es auch mit verschiedenen Schichten mit dem gleichen Ergebnis getestet.

Ich weiß nicht, ob es einen Fehler gibt oder ob es eine Art Konfiguration für die Ebene gibt, die ich auf dem Server nicht richtig mache ...


UPDATE 03/03/2016

Ich habe auf QGIS Server und QGIS Desktop auf 2.12.3 aktualisiert und das Problem besteht weiterhin.

Nach vielen Testtagen habe ich endlich herausgefunden, wann das Problem auftritt. Ich passiert, wenn ich Änderungen des Layers in QGIS (über WFS-T) speichere und gleichzeitig eine Lizmap Map von einem anderen Benutzer geladen wird. Lizmap verwendet auch qgis-server.

Es sieht so aus, als ob Lizmap beim Laden einer Karte den Server beschäftigt und wenn eine WFS-T-Aktualisierungsanforderung empfangen wird, QGIS Server die UPDATE SQL-Abfrage nicht korrekt erstellen kann. Beispiel:

Wenn zum Zeitpunkt des Empfangs des WFS-T-Posts eine Lizmap geladen wird, lautet die in qgis-server generierte PostgreSQL-Abfrage:

2016-03-03 11:47:30 CET LOG:  00000: sentencia: UPDATE "public"."getxo_alumbrado_tendido_canalizacion" SET "diametro"='22' WHERE NULL

Wenn der qgis-Server beim Eintreffen des WFS-T keine Daten für eine ladende Lizmap bereitstellt, lautet die generierte PostgreSQL-Abfrage:

2016-03-03 11:46:21 CET LOG:  00000: sentencia: UPDATE "public"."getxo_alumbrado_tendido_canalizacion" SET "diametro"='111' WHERE "id"::text='1' 

Beachten Sie den Unterschied in der where-Klausel. Der erste macht nichts. Der zweite funktioniert gut.

Ich weiß nicht, ob ich Apache oder Konfigurationsdateien für qgis-server optimieren kann, um dieses Problem zu beheben.

Ich habe versucht, dem Server viel mehr Hardware (4 Kerne und 16 GB RAM) ohne Änderungen zur Verfügung zu stellen.


Ich mache alle Software-Updates mit OSGEO4W. Ich habe irgendwo gelesen, dass Apache- und PHP-Pakete seit Jahren nicht mehr aktualisiert wurden. Ich werde versuchen, sie manuell zu aktualisieren und zu überprüfen, ob die Apache- oder PHP-Version nicht die Ursache des Problems ist.


UPDATE 16/03/2016

Ich habe Apache- und PHP-Pakete aktualisiert und das Problem geht weiter. Nach mehreren Tests stellte ich fest, dass beim Speichern von Editionsänderungen (über WFS) beim Laden einer Lizmap-Karte das Speichern fehlschlägt, in einigen anderen Fällen jedoch weiterhin fehlschlägt, obwohl keine Lizmap geladen wird (bei geringerem Volumen). Es ist ein Problem in QGIS Server (qgis_mapserv.fcgi.exe).


Können Sie QGIS-Serverprotokolle anzeigen, wenn es funktioniert? Ich gehe davon aus, dass sie gleich aussehen, aber wir müssen diese Annahme bestätigen.
AlexGIS

@alexGIS Ja, sie sind gleich. Ich habe eine Antwort mit der Lösung des Problems geschrieben. Danke für Ihre Hilfe!
Egidi

Antworten:


7

Schließlich gab mir Matthias Kuhn , einer der Entwickler von QGIS, den Schlüssel.

Die WHERE-Klausel überprüft den Typ des Primärschlüssels der Tabelle. Es sollte eine Ganzzahl sein und in einigen meiner Tabellen habe ich gesehen, dass der Typ Numerisch (8,0) war.

Diese Tabellen und Primärschlüssel wurden vor einiger Zeit von einer Drittanbieter-App erstellt.

Ich habe den Typ in Integer geändert und alle Tests, die ich seitdem durchgeführt habe, haben funktioniert (ich habe mehr als 100 Editionstests über WFS durchgeführt, meiner Meinung nach genug, um zu dem Schluss zu kommen, dass das Problem gelöst wurde).

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.