[udig-devel] Re:

[David Blasby]

Jesse,

I agree with what you're saying - this is almost certainly the case that 
the postgis datastore is not properly dealing with <Function> elements 
in the Filter.  It should be split into handled-by-DB and 
handled-by-Geotools-JAVA.  I'm sure there's just no <Function>-to-SQL 
implemetation for <Function> clause as no one really uses them.  The 
previous testing I did was with SLD, which used to be all processed in java.

If you can send me an XML GetFeature request I can probably track the 
problem down and fix it.  It should be in the geoserver log (or you can 
easily get it from the WFS datastore) - the stack trace you sent me has 
it just cut off at the very top of the file.

dave

Jesse Eichar wrote:

> The issue depends on the datastore.  For WFS datastore the filter is  
> encoded and sent to the server where the exception seems to occur  
> while parsing the filter.   The exception is attached to this email.   
> For PostGIS the exception occurs when the Datastore tries to encode  
> the filter as SQL.  It says "function filters not supported".  Which  
> is understandable but what isn't acceptable is that an exception is  
> thrown.  The function filter should not be encoded as SQL and the  
> datastore should run the filter on the client.  I know the JDBC  
> datastores have a concept of pre and post filters just for that kind  
> of situation.
>
> Jesse
>
> On 28-Apr-06, at 3:17 PM, dblasby at openplans.org wrote:
>
>> Justin very recently fixed a bug with how <Functions> were being  
>> parsed.
>>
>> So, where is the problem actually occuring - in the parsing or in how
>> the datastore processes the Filter?
>>
>> dave
>>
>> ----------------------------------------------------------
>> This mail sent through IMP: https://webmail.limegroup.com/
>