MapGuide Open Source:  Home |  Download |  Internals

Ticket #254 (closed defect: fixed)

Opened 1 year ago

Last modified 7 months ago

Failed Layer Filters should be logged to error.log

Reported by: zspitzer Assigned to:
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

09/09/07 23:10:01 changed by tomfukushima

  • external_id set to 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

09/10/07 21:46:35 changed 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

10/17/07 02:17:38 changed 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 :)

10/17/07 02:18:45 changed by jbirch

  • milestone deleted.

No assignee, removing milestone.

10/17/07 08:50:34 changed by zspitzer

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

10/19/07 05:40:04 changed 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

10/19/07 13:57:07 changed by jbirch

  • priority changed from medium to high.

10/19/07 14:41:50 changed by jbirch

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

10/19/07 14:44:51 changed by jbirch

  • milestone set to 2.0.

02/07/08 13:06:46 changed by ronnielouie

  • status changed from new to closed.
  • resolution set to fixed.

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.

02/07/08 22:14:52 changed by zspitzer

The changeset seems to be for something else?

02/07/08 23:20:57 changed 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