Re: [Geotools-gt2-users] dynamic text search queries in postgresql - tsvector column type

[Andrea A. <aa...@op...>]

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.

But generally speaking, filter functions should be general.
The functions come from the Filter spec and they are declared
in the WFS capabilities document as a general thing. If the
server exposes only data coming from postgis the caps document
remains truthful, but otherwise you're advertising there
a filter function that will work only against selected layers
(without any way to state against which ones).
Wondering if those functions could be marked some way so that
we don't actually advertise them back in the capabilities
documents.

Cheers
Andrea