[Geoserver-devel] [jira] Created: (GEOS-1979) CQL filters causing StreamingRenderer failure

CQL filters causing StreamingRenderer failure
---------------------------------------------

                 Key: GEOS-1979
                 URL: http://jira.codehaus.org/browse/GEOS-1979
             Project: GeoServer
          Issue Type: Bug
          Components: WMS
            Reporter: Saul Farber
            Assignee: Andrea Aime
             Fix For: 1.6.5, 1.6.x
         Attachments: getmapresponse_propnames-1.6.x.patch

Consider the following scenario:

Geoserver 1.6.x latest revision: WMS GetMap on a bbox with a CQL filter like (PROP1 = 'value2')

1. In GetMapResponse.java on line 161 the parsed CQL gets turned into a combined filter (cql + layer def filter)
2. In GetMapResponse.java around line 313, the combined filter gets added to the query for that layer, however the propertyNames for that query are left at null (= all properties?)
3. In StreamingRenderer on line 715, the definition query from the layer and the bbox query from the StreamingRenderer are mixed together using DataUtilities.mixQueries(). However DataUtilities.mixQueries interprets query.propertyNames = null as NO properties (as opposed to ALL properties as in point 2.) See line 1401 in DataUtilities.java.
4. This means that the query to the datastore only asks for the explicitly named properties (namely the geometry property from the bbox filter), but that the call to iterator.next() (StreamingRenderer.java line 1599) will probably fail as the datastore is returning a single attribute and the iterator is expecting at least two attributes.

I was able to fix this with the attached patch. It explicitly extracts all required attributes out of the combined filter and applies them to the query created in 2. I tried to run the tests but got other (extraneous?) failures in SVG and KML rendering that I'll look into.

Note that the comments around line 687 make me think that this new queryLayer() implementation might have exactly these sorts of issues. I think the discrepancy between how 4. treats the propertyNames = null and 2. treats propertyNames = null should be addressed at some level. This patch just makes things explicit while not solving that problem.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira