On Tue, Jul 27, 2010 at 2:52 AM, Andrea Aime <[email protected]> wrote:
> Jody Garnett wrote:
>> I was actually thinking about this one for work last week. I had thought
>> to make a GeoTools search and function; and then adjust the sql encoder
>> to encode it if the textsearchable_index_col is a match. That is kind of
>> where my thinking stopped; figured I would talk to justin about it if I
>> get paid.
>>
>> An alternative is aaime's recent work allowing you to define your own
>> SQL "view".
>>
>> I do not recommend extending filter or like filter (since it represents
>> a controlled data structure that must be emulated on WFS, SQL, shapefile
>> etc...).
>>
>> The filter data structure is however extendable in two ways:
>> - functions (you can define your own functions as above)
>> - property accessors (you can teach the filter to work on more kinds of
>> content then just features)
>>
>> The interesting question for me is how the internals of the JDBC-NG
>> datastore's handle encoding a filter into SQL; and if there are any
>> hooks already defined which you can use to teach it how to handle
>> specific functions.
>>
>> There is a dialect object which contains all the database specific work
>> in one spot; when I last looked the code responsible for doing the
>> SELECT statement was duplicated a few times but that could be fixed to
>> recognise a specific "function encoding" opportunity.
>
> The sql encoding is not done by the dialect, but by a FilterToSQL
> subclass, each specific for a database.
> There you could recognize a function and encode it.
>
> The tricky part is that to do it properly, to make the function
> something worth contributing back to geotools, it should be able
> to work stand alone in memory as well. Otherwise we end up with
> a function that actually just work against PostgreSQL.
> Which... well... might be acceptable too, if it's documented
> very clearly.

My suggestion to Scott was to extend the way the PostGIS datastore
encoded a like filter if the column it was against was a TS_Vector to
use @@ instead of like. For an end user there would be no difference
(except for a speed up if available). If other databases provided a
similar function they could be extended in a similar way.

For shapefiles and memory stores it might be worth leveraging Lucene
but to be honest I'm not sure that people should be considering that
sort of query against large shapefiles etc.

Ian
-- 
Ian Turton

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to