app-schema gives error response to WFS 2 GetFeatureById stored query


If I install GeoServer and then set the data directory to be the tutorial data that comes with the app-schema plugin and execute the query below:

http://localhost:8080/geoserver/ows?service=wfs&version=2.0.0&request=GetFeature&storedquery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&id=mf.25699& - http://localhost:8080/geoserver/ows?service=wfs&version=2.0.0&request=GetFeature&storedquery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&id=mf.25699&

I get the error response:

<ows:ExceptionReport version="2.0.0" xsi:schemaLocation=" http://localhost:8080/geoserver/schemas/ows/1.1.0/owsAll.xsd - http://localhost:8080/geoserver/schemas/ows/1.1.0/owsAll.xsd"><ows:Exception exceptionCode="OperationProcessingFailed" locator="GetFeature"><ows:ExceptionText>No feature types specified</ows:ExceptionText></ows:Exception></ows:ExceptionReport>

With a stored query, it shouldn't be necessary to specify a feature type.

Note the core GeoServer WFS partly supports this query although the response isn't quite the correct format: see -




Daniel Urda
May 16, 2018, 4:14 PM

I've made a pull request that solves the problem lazily by going through all app schema feature types published in the catalog (the brute force solution suggested by bencaradocdavies). Admittedly, for large datasets that use CQL expression for the idExpression in the app-schema config file (e.g. by concatenating one or more fields, or a field and a constant string; this is discouraged by the documentation) it may take a very long time to resolve the query. For well-behaving app-schema datasets (with idexpression mapped to a field) it works pretty good even for many large datasets

April 10, 2015, 3:54 PM

CodeHaus Comment From: bencaradocdavies - Time: Tue, 5 Aug 2014 04:50:59 -0500
<p>As I mentioned to Tim last week, I see a straightforward solution: allow mapping files to specify a gml:id prefix that they promise will be at the start of the gml:id of features of that feature type and not of features of other types. For example, if serving MappedFeature with gml:id starting with "my_mapped_feature.", this prefix would be declared in the mapping file and recorded in the app-schema data store.</p>

<p>The next step is to change the current prefix-guessing approach in the core GetFeatureById implementation to place the responsibility for selecting a data store on the data stores themselves. This is an API change and will require a proposal. Each ordinary data store can continue to guess based on its table name, and an app-schema store can provide an authoritative answer as to whether it can handle such a request based on the configured prefix. This allows the dispatcher to choose the correct data store without brute forcing the database.</p>

<p>Some data owners may require multiple prefixes; there will need to be an assessment of how much variation in gml:id can be supported. The requirement is that a request can be dispatched to the correct store quickly without querying the database. Or perhaps brute force should be an option? For every GetFeatureById request, every app-schema data store is queried (and thus SQL database is queried) to see if any features match. This will have significant performance implications for servers with many data stores.</p>

April 10, 2015, 3:54 PM

CodeHaus Comment From: bencaradocdavies - Time: Tue, 3 Jun 2014 21:50:58 -0500
<p>The underlying problem is that the core GetFeatureById implementation parses the gml:id (which is meant to be opaque) to extract the table name part and use this to guess to which data store this request should be dispatched. This does not work with app-schema as gml:id is typically unrelated to the feature type name. Fixing this will require a different approach. </p>





Affects versions