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

Description

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:

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.

Environment

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

Activity

Show:
Carsten Klein
January 22, 2019, 7:33 AM

Any updates on that? What could I do to get this issue some more focus?

Andrea Aime
January 22, 2019, 9:29 AM

If you need it within a given deadline, there are pretty much only two options:

Carsten Klein
January 22, 2019, 10:05 AM

Thanks a lot for your response, Andrea, At present, I can live with omitting the value tag. I'm likely not prepared for providing a fix myself (so far, I've got too little knowledge of the internals). However, would be quite challenging.

Assignee

Unassigned

Reporter

Carsten Klein

Triage

None

Fix versions

None

Affects versions

Components

Priority

Medium
Configure