We are currently using Oracle 11g as our database with GeoServer 2.10.2. (We
would like to upgrade, but 2.11.0 and above cannot seem to get our catalog set
up correctly from the existing 2.10.2 app-schema-cache.)
We are using an externally developed XML schema (we cannot change it) that
codes some data as attributes rather than element values. E.g., Feature2 has an
associatedFeature1 element. The primary key for any feature is the combination
of values from two columns, CODESPACE and UUID. In the schema, Feature2 codes
its associatedFeature1 this way:
...
<!-associatedFeature1 is coded as an attribute of the otherwise empty XML
element -->
<ns1:associatedFeature1 xlink:href="my:code:space:longhexidecimalUUIDstring"/>
<!-price is coded as an element value, as one would normally expect -->
<ns1:price>127.83</ns1:price>
...
Both of these data elements come from non-indexed columns of the table, which
has 20,000 rows. When we query on price, the one matching Feature2 comes back
very quickly.
<fes:Filter>
<fes:PropertyIsEqualTo>
<fes:ValueReference> ns1:price</fes:ValueReference>
<fes:Literal>127.83</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
When performing a WFS query on associatedFeature1, however, the SOAP request
filter syntax is:
<fes:Filter>
<fes:PropertyIsEqualTo>
<fes:ValueReference>
ns1:associatedFeature1/@xlink:href</fes:ValueReference>
<fes:Literal>my:code:space:longhexidecimalUUIDstring</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
A direct SQL query for the HREF on that table is instantaneous. However, the
WFS query takes nearly 2 minutes to return the four matching Feature2 values.
It appears to be doing what older versions of GeoServer also do for geolocation
searches - rather than using the WHERE clause of the SQL query, it downloads
the complete contents of the table to GeoServer and does its own row-by-row
search for a match. The element value search is clearly adding a WHERE clause
in order to return so quickly.
I can find no mention of this issue in any web search. Does anyone know if this
is fixed in a later version of GeoServer as the geolocation search has been
improved to code it in the SQL WHERE clause? Or is this issue of searching on
an attribute value vs. an element value so unusual that nobody has ever seen it
before?
---------------------------------------------------------------
Michael Stein, Northrop Grumman Defense Systems
7555 Colshire Dr 4098S
McLean, VA 22102
703-963-6654(cell); 301-429-5468(ofc)
_______________________________________________
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
