#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 , 17 years ago
External ID: | → 963656 |
---|
comment:2 by , 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 , 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:5 by , 17 years ago
I have logged ticket:289 as separate ticket, don't render anything when a layer filter fails
comment:6 by , 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 , 17 years ago
Priority: | medium → high |
---|
comment:8 by , 17 years ago
Re-establishing milestone. No promise, just an indication of my support.
comment:9 by , 17 years ago
Milestone: | → 2.0 |
---|
comment:10 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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:12 by , 17 years ago
Right changeset, but Trac is definitely doing something odd with the R in the URL. This is the correct one:
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