Opened 11 years ago

Closed 11 years ago

Last modified 11 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 Changed 11 years ago by tomfukushima

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 Changed 11 years ago by zspitzer

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 Changed 11 years ago by jbirch

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 Changed 11 years ago by jbirch

Milestone: 2.0

No assignee, removing milestone.

comment:5 Changed 11 years ago by zspitzer

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

comment:6 Changed 11 years ago by zspitzer

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 Changed 11 years ago by jbirch

Priority: mediumhigh

comment:8 Changed 11 years ago by jbirch

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

comment:9 Changed 11 years ago by jbirch

Milestone: 2.0

comment:10 Changed 11 years ago by ronnielouie

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 Changed 11 years ago by zspitzer

The changeset seems to be for something else?

comment:12 Changed 11 years ago by jbirch

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.