> My initial feedback was more about how to advertise what functions are
> available -
allowing only these functions is possibly the higher priority.
> so geoserver can report them as available etc.
>There is one thing to check in the WFS specification; I am under the
impression that server n
gton); [EMAIL PROTECTED]; [email protected]
Subject: Re: [Geotools-devel] Registered function support for JDBC
databases
Rob Atkinson wrote:
> hmm - IMHO not having to get a WFS change request is starting small.
> Just accepting that we can get the functionality workin
Hi Ben :-) It is great to have you working in this space - I only wish
you were working on trunk (since this is an active area of development).
> I had originally intended to use one dynamic proxy class for each
> function, because FilterCapabilities has a one-class to one-function
> mapping, bu
Jody Garnett wrote:
> A couple things; executing any sql function is not a good thing from a
> security standpoint (but you know this).
Indeed.
> You should be able to advertise
> additional functions on a data store by datastore basis using the filter
> capabilities data structure. You are th
Rob Atkinson wrote:
> hmm - IMHO not having to get a WFS change request is starting small.
> Just accepting that we can get the functionality working and work out
> how to advertise it later (i.e. there isnt really much point
> advertising it if its feature specific) seems to me a much lower bar
hmm - IMHO not having to get a WFS change request is starting small. Just
accepting that we can get the functionality working and work out how to
advertise it later (i.e. there isnt really much point advertising it if its
feature specific) seems to me a much lower bar. Getting the big picture
righ
[EMAIL PROTECTED] wrote:
> Ahh! Herein lies a quandry. WFS doesnt allow per feature functions to be
> advertised, and most interesting features have implicit or explicit
> operations that would be nice to advertise per feature as functions.
> Ideally, those functions are only allowed on those f
Rob Atkinson wrote:
> There is nothing intrinsically postgis about the solution, we envisage
> it a JDBC capability.
I agree :-)
> A parameter with a sensible default could advertise the table or
> function that would be interrogated to find functions intended to be
> advertised.
>
> My could a
There is nothing intrinsically postgis about the solution, we envisage it a
JDBC capability.
A parameter with a sensible default could advertise the table or function
that would be interrogated to find functions intended to be advertised.
My could attempt to call a function
getRegisteredFunctions
A couple things; executing any sql function is not a good thing from a
security standpoint (but you know this). You should be able to advertise
additional functions on a data store by datastore basis using the filter
capabilities data structure. You are the first person to want to do this
so pl
10 matches
Mail list logo
