I would like to see support for functions dynamically discoverable from
data sources. The use case is a database that exposes functions that can
be called in a filter query. GeoTools will not know about these
functions until it connects to the database. If the data store is
configured to permit it, the functions are passed to the database for
execution.
The "registered functions" prototype in community-schemas does this by
overriding bits of FilterFactoryImpl. In effect, any unknown function is
passed to the data store as a fallback, and the data store SQL encoder
will have to decide whether it should be encoded.
It would be good if the new filter arrangements support this approach,
or at least, do not make it unimplementable.
Andrea Aime wrote:
> Hi,
> so following up from last week discussion, it
> seems there is currently no supported way to know
> what the arguments of a function are, you are
> supposed to know before hand (Jody mentioned
> the FunctionFinder, but that does not provide
> any argument lookup method).
>
> So it seems that to get unstuck I will have to
> make a change proposal affecting both GeoTools
> and GeoApi.
>
> In particular, I'm thinking to propose something
> along these lines:
> - register a factory for the functions, not the
> functions themselves
> - a factory can create multiple functions and
> provide metadata about them (the number of
> arguments and the return type, -1 if the
> number of arguments cannot be determined
> beforehand)
> - for most of the existing functions implementing
> FunctionExpression, we can just create a factory
> that looks up the functions, and grabs the
> metadata using the FunctionExpression interface
> (which we could un-deprecate if we make it stop
> extending org.geotools.filter.Expression)
> - for the few others (if any) a new factory
> will be created
>
> This would solve the lookup issue at the GeoTools
> level. At the GeoApi level things are a bit more
> complicated because the function lookup support
> has been mutilated quite a bit.
> We should at least:
> - add back FilterCapabilities to FilterFactory
> - add getFunctions to FilterCapabilities,
> which in turn provides the getFunctionNames
> and getFunctionName methods
> - decide if FunctionName interface is good for
> us, or not. At the moment we do have the following:
>
> public interface FunctionName extends Operator {
> /**
> * Number of arguments the function accepts.
> */
> int getArgumentCount();
>
> /**
> * Argument names for documentation purposes if known.
> List<String> getArgumentNames();
> }
>
> Hum, no types? Oh well, I could go for that. Going into
> all the function implementations and adding the name
> metadata can be somewhat painful, but as a stop gap
> measure we could just name them "arg1", "arg2", ...
> in FunctionExpressionImpl.
>
> Opinions?
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Ben Caradoc-Davies <[EMAIL PROTECTED]>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
