[Geoserver-devel] [JIRA] (GEOS-8984) Different handling of empty strings and NULL values passed through WFS-T update requests

GeoServer GeoServer Developer
1

Carsten Klein created an issue

GeoServer / BugGEOS-8984

Different handling of empty strings and NULL values passed through WFS-T update requests

Issue Type:

BugBug

Affects Versions:

2.14.0

Assignee:

Unassigned

Components:

WFS

Created:

24/Oct/18 12:38 PM

Environment:

Java 8 (both OpenJDK and Oracle), Apache Tomcat 7 or Apache Tomcat 8.5, PostgreSQL 9.3 (Linux), Ubuntu Linux, Windows 8.1

Priority:

MediumMedium

Reporter:

Carsten Klein

Hi there,

current versions of GeoServer seem to handle empty strings and NULL values passed through WFS-T update requests differently than in older versions (2.8.x). We are unable to set fields to an empty string and must change the way we provide NULL values. That used to work with version 2.8.x. After moving to version 2.13.0 some time ago, we encountered the new behavior for the first time. It’s still present in current stable version 2.14.0.

Have a look at this WFS-T Update request, which updates some fields in a PostgreSQL database:

  [...] transaction element not dumped here
  <wfs:Update typeName="table_name" xmlns:dummy="http://www.dummy.de/geo/test">

    <wfs:Property>
      <wfs:ValueReference>text_column_1</wfs:ValueReference>
      <!-- Value element omitted: results in a real null value -->
    </wfs:Property>

    <wfs:Property>
      <wfs:ValueReference>text_column_2</wfs:ValueReference>
      <!-- Value element with no content, results in '{}', wrong behavior -->
      <wfs:Value />    <!-- (recommended by OGC) -->
    </wfs:Property>

    <wfs:Property>
      <wfs:ValueReference>text_column_3</wfs:ValueReference>
      <!-- Value element with empty string, results in '{}', wrong behavior -->
      <wfs:Value></wfs:Value>
    </wfs:Property>

    <fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0">
      <fes:ResourceId rid="table_name.1234" />
    </fes:Filter>
  </wfs:Update>

As far as I remember, with GeoServer 2.8.x, text_column_2 would have been set to NULL, whereas text_column_3 would have been set to an empty string.

Now, for columns text_column_2 and text_column_3, a recent GeoServer internally seems to use string "{}" instead of a Java null value or an empty string, respectively. For example, when setting a database field to NULL that way with a WFS-T Update request, the field is set to the string '{}' if it’s a character field (varchar, text, etc). A service exception Could not map back {} to type java.sql.Timestamp is thrown, if it’s not a character field (timestamp in that case).

So, actually NULL values can only be passed by omitting the wfs:Value element, using a wfs:Value element with no content (which is the OGC recommended way to express NULL, see 15.2.5.2.1 Property element, 2nd paragraph) does not work. Furthermore, it is no longer possible to pass an empty string, since GeoServer seems not to distinguish between <wfs:Value /> and <wfs:Value></wfs:Value> and so, runs into the same problem in both cases and falsely uses string "{}" as the property’s value.

We’ve run GeoServer 2.14.0 in a local Tomcat server in Eclipse (using prebuilt binaries (JARs) with sources attached) and did some debugging. It turned out, that the parsed request contains empty HashMap instances for each property’s value, that should be a null value or an empty string. The toString() method of an empty map returns "{}", which likely explains, why GeoServer continues work with those curly braces.

In XML, an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag, so, there is per se no distinction between these two forms. OGC recommends using an empty value element to represent NULL. If GeoServer has now decided to represent NULL by a missing value element, that’s OK (but not really documented). However, there is still no way to represent an empty string. An empty element would be an option (since it’s not/no longer used to represent NULL). Either way, empty value elements result in GeoServer working with "{}", which is likely not intended by the requester in most cases.

Since the XML request is actually parsed by GeoTools, this may as well be a GEOT issue. Also, AFAIK, this only applies to property values sent with WFS-T Update and (maybe) Insert requests. WFS filters work well with empty Literal strings.

Add Comment

Add Comment

Get Jira notifications on your phone! Download the Jira Cloud app for Android or iOS

This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100094-sha1:052c2c8)

Atlassian logo