Hi Andera:
This is exciting; I am still sorting out the context of how this is to be used
at the end of the day. Is this something like the WFS 2.0 "predefined queries"
(I always thought those were more for prepared statements but setting up
something in the middleware is more sane actually)
Or is this something that is define against a feature store showing up as
another "featureSource" in the list?
Or is really done on a per Query basis?
So I have been kind of keeping quiet until I could figure out what is going
on...
Jody
On 21/06/2010, at 6:39 PM, Andrea Aime wrote:
> Hi,
> some time ago I've sent this message to the mailing list,
> and only Michael answered.
>
> I'm quite likely to get funding to implement it, so please,
> if you have feedback, speak :-)
>
> -----------------------------------------------------------
>
> Hi,
> as you all probably know thanks to Michael work we recently got the
> ability to peform on parameter substitution in SLD and filters
> courtesy of the EnvFunction filter function.
>
> That is great and adds a great deal of flexibility to styling
> without significant risks, as the params are either evaluated
> in memory or properly parsed into a target type (actually,
> just evaluated in memory now, but let me face that topic
> in another mail).
>
> Now I'm looking into ways of doing something similar for the
> VirtualTable support in JDBC data stores.
> VirtualTable allows people to create a new feature type by
> just providing a sql statement (plus a bit of metadata).
>
> Now, what I'm looking into doing is to add param replacement
> in that sql statement, something like:
>
> select a.*, b.*
> from a inner join b on a.id = b.fk
> where a.size > ${param}
>
> or if the query is a call to a stored procedure:
>
> call myProcedure(10, 15, ${param})
>
> The parameters would be explicitly declared in the VirtualTable,
> and would be associated to a default value (so that the query is
> always runnable) and to a validation regular expression.
> The latter is crucial to avoid sql injection attacks, the regexp
> should make sure no extra statements are embedded in the mix
> (a good default regexp should probably disallow ; and ').
>
> So the VirtualTable would have a new array of Parameter,
> where parameter has a name, a default value (String) and
> a validation regular expression
>
> Now, an interesting question is, how do we pass down parameters?
>
> We are making queries, so a natural way would be to pass
> them down as query parameters, something like:
>
> Query q = new Query(...);
> q.setHints(new Hints(Hints.SQL_PARAMS, myStringStringMap)
>
> However there is another way that could be of interest: use
> again EnvFunction. This would make param passing consistent
> with SLD substitution:
>
> try {
> EnvFunction.setLocalValues(myStringStringMap);
> ... do query, render, whatever
> } finally {
> // if you want to clean up the thread local params map
> EnvFunction.clearLocalValues();
> }
>
> and then internally the store would invoke:
>
> env = new EnvFunction().setParameters(singletonList("myParamName")
> String value = env.evaluate(null, String.class);
>
> The advantages I see in this approach are:
> - just one way to setup and retrieve "environmental" values in GeoTools
> - does not require to fiddle with setting up Queries in MapLayer
> just for the sake of passing down hints when rendering a parametrized
> view layer
> - the env function is somewhat more flexible in that it allows both
> per thread and global enviroment values (see
> EnvFunction.setGlobalValues(...)
>
> Opinions?
>
> -----------------------------------------------------------------------
>
> Cheers
> Andrea
>
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
