Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#254 closed defect (fixed)

Failed Layer Filters should be logged to error.log

Reported by: zspitzer Owned by:
Priority: high Milestone: 2.0
Component: Resource Service Version: 1.2.0
Severity: major Keywords:
Cc: External ID: 963656

Description

Apparently when a layer filter fails on a feature source, mapguide will then re-try the query without the filter automatically. This happens without any logging which makes tracking down errors very difficult.

This error should be written to the error log, with any feedback error message from the FDO provider if possible

Change History (12)

comment:1 by tomfukushima, 17 years ago

External ID: 963656

Hi, thanks for taking the time to enter this ticket. Can you explain why you came to the conclusion that MG retries without the filter automatically? I'm not saying this is wrong; I'm just trying to get more information to help developers pinpoint the problem. Thanks. Tom

comment:2 by zspitzer, 17 years ago

it's easy to test, enter in a bad filter into a layer definition which isn't valid and see what happens... if your using a database like oracle you monitor the sql being passed...

background on this is that i have an issue with King Oracle 0.7.3 where filters aren't being applied.

Harris told me about this...

i would prefer no data is returned when a filter fails

comment:3 by jbirch, 17 years ago

I have seen this in the logs when testing the PostGIS provider without a user-defined filter. This happened when we had a problem with the spatial filters not working and they were throwing exceptions.

First MapGuide would try with the spatial filter exception thrown, then again (maybe with a different spatial filter? Intersects instead of EnvelopeIntersects? I'm a bit fuzzy on this now) and finally without any spatial filter at all.

It seems to me that this behaviour is less desirable than determining if a provider supports that filter in it's capabilities, and then failing if the provider throws an exception. The other case (silently getting everything) leads the user trying to figure out why their map is taking so bloody long to load :)

comment:4 by jbirch, 17 years ago

Milestone: 2.0

No assignee, removing milestone.

comment:5 by zspitzer, 17 years ago

I have logged ticket:289 as separate ticket, don't render anything when a layer filter fails

comment:6 by zspitzer, 17 years ago

Looking at the the King Oracle source code, there is this type of exception which looks like it would provide the error message for the log ie (from c_KgOraFilterProcessor.cpp)

throw FdoFilterException::Create(L"FdoNullCondition is missing the property name");

http://svn.osgeo.org/fdo/trunk/Providers/KingOracle/src/Provider/c_KgOraFilterProcessor.cpp

comment:7 by jbirch, 17 years ago

Priority: mediumhigh

comment:8 by jbirch, 17 years ago

Re-establishing milestone. No promise, just an indication of my support.

comment:9 by jbirch, 17 years ago

Milestone: 2.0

comment:10 by ronnielouie, 17 years ago

Resolution: fixed
Status: newclosed

The Fdo exception that occurs when the layer is rendered is basically ignored and no error is written to the log. Changed the code such that instead of silently ignoring the error, it will be written the the log. http://trac.osgeo.org/mapguide/changeset/r2616.

comment:11 by zspitzer, 17 years ago

The changeset seems to be for something else?

comment:12 by jbirch, 17 years ago

Right changeset, but Trac is definitely doing something odd with the R in the URL. This is the correct one:

http://trac.osgeo.org/mapguide/changeset/2616

Note: See TracTickets for help on using tickets.