Folks,
our intention was to use Geoserver 1.3.0 to cope with some strange
effects of UMN Mapserver serving WFS requests. We use RC3 in a Tomcat
5.0 on a linux box. Data Source below is Oracle Spatial 9.2.0.4
connected via thick client.
Our table contains several VARCAHR fields which identify land lots. The
field values are all numeric (e.g. 12345), but cannot be stored in
numeric fields due to some legacy software.
Everything seems to work fine unless we impose a filter like
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>GMNR</ogc:PropertyName>
<ogc:Literal>3819</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
Oracle "performs" a table scan, which takes approx. 10 min.
We digged into this and found the SQL-statement in catalina.out - it
contains a WHERE clause similar to:
WHERE "GMNR" = 3819
That is, the filter implementation resolves our alphnumeric value 3819
to an integer. Obviously, this causes Oracle not to use its index ...
When we add some extra characters like 3819A or similar, the WHERE
clause is altered to
WHERE "GMNR" = '3819A'
which is really quick - but doesn't reveal any results!
Our questions:
1. Is there any quick workaround, like forcing the filter Impl not to
guess the type?
2. Is this a feature or is it a bug? If so, is it related to bug
GEOT-122 (see http://jira.codehaus.org/browse/GEOT-122)
3. If yes, how can we deploy a new GeoTools lib (partly) into an
existing geoserver installation? Or, will it be included in the next
release?
I already posted this one in geoserver-devel and Dave gave me the
advice to cross-post it here.
Any hint welcome - thanks in advance,
Jürgen
Noch allein? 1 Million Singles warten auf ein Date!
Schnell Kontakt aufnehmen bei Deutschlands beliebtester Partnerboerse
http://singles.freenet.de/index.html?pid=11512
