Thanks Andrea that helped; that is actually a match with with BIRT does in
their various query builders; indeed your work would ease integration greatly.
Jody
On 21/06/2010, at 11:18 PM, Andrea Aime wrote:
> Jody Garnett ha scritto:
>> 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...
>
> By parametrized sql queries I really mean raw, native sql, in which you
> can poke holes with parameters that will be provided by the user.
>
> It is something like WFS 2.0 predefined queries, but here you can
> really pass down full sections of sql, not just values (and it's
> your duty to design a regexp that will protect such usage from
> sql injection). E.g., if you're feeling adventurous or you're
> just controlling very tightly your execution environment so that
> sql injection attacks are impossible you can do something like:
>
> select a, b, c
> from my table {param}
>
> and then pass as "param" values like
> "inner join table2 on ... where ..."
> or
> "where table.d > 25 and nativeFunction(table.a) = 27"
>
> As long as the result structure of the query is stable you can do
> pretty much what you want. At your own risk btw, I would limit
> myself to simple value substitution where I can specify that
> something is a number or a string without quotes and so on
> (a very well constrainted regular expression, that is).
>
> It has nothing to do with querying feature sources, it's really raw sql,
> there is no abstraction, it's bare metal against the database
> you're using. Whatever you provide goes straight to the db as is.
>
> As I said in the message I'm not going to use Query as the transport
> method for the "parameters", but the env filter function instead
> for uniformity with sld param substitution. I already suggested
> this before and nobody complained.
>
> If you still miss context/clarification just ask
>
> 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
