I thought of suggesting that as well; was not sure how carefully he wanted to reflect the WFS Like definition.
But yes that would work; good thinking. Jody Aside: I apologize for my original response sounding mercenary. I am not holding a solution hostage for money; I simply had thought through this process very recently and had some ideas on hand. I would be more then happy with anyone doing the work and submitting a patch for review (heck I would like to use the solution as well). On Wed, Jul 28, 2010 at 4:45 AM, Ian Turton <[email protected]> wrote: > 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
