I like your thinking Justin.
So if stored queries are sufficiently whacky enough we can create a new
interface:
public class FeatureQuery {
FunctionName getFunctionNames();
FeatureCollection storedQuery( Function );
}
public class SimpleFeatureQuery extends FeatureQuery{
SimpleFeatureCollection storedQuery( Function );
}
The above depends FunctionName which describes both the name of the query
and the available parameters.
Jody Garnett
On Mon, Apr 14, 2014 at 11:53 PM, Justin Deoliveira <
jdeol...@boundlessgeo.com> wrote:
>
>
>
> On Fri, Apr 11, 2014 at 5:54 AM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Hi justin,
>>
>> Maybe stored queries might be represented as a dimension for the layer.
>> The default dimension would be to use no stored query, while stored queries
>> returning values for that particular feature type would be values for that
>> dimension. What do you think?
>>
>
> I am not exactly sure what this woudl look like. Can you elaborate?
>
> I wonder if trying to represent it as a filter function makes more sense.
> The same way that jdbc datastores map filter functions to native functions
> the wfs datastore could map filter functions to stored query calls? Problem
> is I don't believe there is any api that would expose such functions...
> aside from having the wfs datastore product an implementation of
> FilterFunctionFactory. Anyways, just a thought.
>
>>
>> And yes, I am checking that the the WFS supports stored queries before
>> doing anything. Which actually brings up a small question regarding the WFS
>> spec: when does a WFS service support executing stored queries? Does it
>> have to support ListStoredQueries or DescribeStoredQueris or both
>>
>
> As Ilkka mentions in his reply these are supposed to be part of the
> lowest level of conformance (which surprised me) but I do still think it
> would be a good idea to check the OperationsMetadata of the capabilities
> document as the authoritative source. Which we will probably want to do
> anyways in order to check whether we can create new stored queries, etc...
>
>>
>>
>> Sampo
>>
>>
>> On Fri, Apr 11, 2014 at 2:24 PM, Justin Deoliveira <
>> jdeol...@boundlessgeo.com> wrote:
>>
>>> Hey Sampo,
>>>
>>> I think what you propose sounds perfectly reasonable. I agree that
>>> stuffing stored queries into a feature type might prove tricky but I am not
>>> sure I see a better way. It is also kind of consistent with the way that
>>> jdbc datastores handle sql views.
>>>
>>> Btw, I am assuming that the wfs client will check the capabilities doc
>>> to see whether stored queries are supported before querying?
>>>
>>> -Justin
>>>
>>>
>>> On Wed, Apr 9, 2014 at 11:49 PM, Sampo Savolainen <
>>> sampo.savolai...@spatineo.com> wrote:
>>>
>>>> Hi Jody (& the list),
>>>>
>>>> Sorry, I should have framed my question better. My question was
>>>> regarding to the WFS DataStore work I'm currently doing, which is writing
>>>> WFS 2.0 Stored Query support to WFS-NG.
>>>>
>>>> At least for the time being, I'm adding the stored queries as special
>>>> feature types the WFS DataStore reports along with the usual feature types.
>>>> For these special feature types, the data store will then use stored
>>>> queries instead of filter queries. As this model requires the data store to
>>>> enumerate all available "feature types" at once, it requires
>>>> ListStoredQueries to happen as GeoServer requests the list of feature
>>>> types. This will then happen immediately as a new wfs-ng DataStore is
>>>> registered and henceforth every time a GeoServer with such a DataStore is
>>>> started. As for the DescribeStoredQuery, I expect that will happen only
>>>> when that "feature type" (or information regarding it) is actually
>>>> requested through the DataStore API. From where I'm sitting, this seem
>>>> acceptable, but feedback and comments are always appreciated.
>>>>
>>>> Fitting the Stored Queries as feature types feels quite crufty though.
>>>> I'd love to get a conversation going if there's a better way to model the
>>>> stored queries.
>>>>
>>>>
>>>> Sampo
>>>>
>>>>
>>>>
>>>> On Thu, Apr 10, 2014 at 1:17 AM, Jody Garnett
>>>> <jody.garn...@gmail.com>wrote:
>>>>
>>>>> When the GetCapabilities document is produced? Since the stored
>>>>> queries are listed in the WFS 2.0 GetCapabilities document right? There is
>>>>> no guarantee that a client will use the GeoServer user interface (since
>>>>> that is just for configuration).
>>>>>
>>>>>
>>>>> Jody Garnett
>>>>>
>>>>>
>>>>> On Mon, Apr 7, 2014 at 10:13 PM, Sampo Savolainen <
>>>>> sampo.savolai...@spatineo.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was wondering if anyone had given thought as to what would be the
>>>>>> appropriate time in the lifecycle of a WFS DataSource to discover what
>>>>>> stored queries are available?
>>>>>>
>>>>>> Would it make sense to run both (or just DescribeStoredQueries
>>>>>> without a query id filter) at the same time the capabilities are loaded?
>>>>>> Or
>>>>>> should the client retrieve the list of possible queries only after the UI
>>>>>> asks for the list of feature types available for a particular WFS Data
>>>>>> Source?
>>>>>>
>>>>>> This has probably been thought through when designing the database
>>>>>> data sources and it would make sense to use the same pattern here.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Sampo
>>>>>>
>>>>>> --
>>>>>> Sampo Savolainen
>>>>>> R&D Director, Spatineo Oy
>>>>>> sampo.savolai...@spatineo.com
>>>>>> +358-407555649
>>>>>> Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
>>>>>> www.spatineo.com, twitter.com/#!/spatineo
>>>>>> www.linkedin.com/company/spatineo-inc
>>>>>>
>>>>>> This message may contain privileged and/or confidential information.
>>>>>> If you
>>>>>> have received this e-mail in error or are not the intended recipient,
>>>>>> you
>>>>>> may not use, copy, disseminate, or distribute it; do not open any
>>>>>> attachments, delete it immediately from your system and notify the
>>>>>> sender
>>>>>> promptly by e-mail that you have done so.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Put Bad Developers to Shame
>>>>>> Dominate Development with Jenkins Continuous Integration
>>>>>> Continuously Automate Build, Test & Deployment
>>>>>> Start a new project now. Try Jenkins in the cloud.
>>>>>> http://p.sf.net/sfu/13600_Cloudbees_APR
>>>>>> _______________________________________________
>>>>>> Geoserver-devel mailing list
>>>>>> Geoserver-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sampo Savolainen
>>>> R&D Director, Spatineo Oy
>>>> sampo.savolai...@spatineo.com
>>>> +358-407555649
>>>> Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
>>>> www.spatineo.com, twitter.com/#!/spatineo
>>>> www.linkedin.com/company/spatineo-inc
>>>>
>>>> This message may contain privileged and/or confidential information. If
>>>> you
>>>> have received this e-mail in error or are not the intended recipient,
>>>> you
>>>> may not use, copy, disseminate, or distribute it; do not open any
>>>> attachments, delete it immediately from your system and notify the
>>>> sender
>>>> promptly by e-mail that you have done so.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Put Bad Developers to Shame
>>>> Dominate Development with Jenkins Continuous Integration
>>>> Continuously Automate Build, Test & Deployment
>>>> Start a new project now. Try Jenkins in the cloud.
>>>> http://p.sf.net/sfu/13600_Cloudbees
>>>> _______________________________________________
>>>> Geoserver-devel mailing list
>>>> Geoserver-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>
>>>
>>> --
>>> *Justin Deoliveira*
>>> Vice President, Engineering | Boundless
>>> jdeol...@boundlessgeo.com
>>> @j_deolive <https://twitter.com/j_deolive>
>>>
>>
>>
>>
>> --
>> Sampo Savolainen
>> R&D Director, Spatineo Oy
>> sampo.savolai...@spatineo.com
>> +358-407555649
>> Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
>> www.spatineo.com, twitter.com/#!/spatineo
>> www.linkedin.com/company/spatineo-inc
>>
>> This message may contain privileged and/or confidential information. If
>> you
>> have received this e-mail in error or are not the intended recipient, you
>> may not use, copy, disseminate, or distribute it; do not open any
>> attachments, delete it immediately from your system and notify the sender
>> promptly by e-mail that you have done so.
>>
>
>
>
> --
> *Justin Deoliveira*
> Vice President, Engineering | Boundless
> jdeol...@boundlessgeo.com
> @j_deolive <https://twitter.com/j_deolive>
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
