[EMAIL PROTECTED] wrote:
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?
Yes - there is. The problem is really with the Oracle SQL writer.
Fitler literals are always strings (it is a fact of life), we try to up
convert them occasionally in geotools code. But the a filter literal is
always intended to be a string.
It is up the the OracleDatastore (in this case) to do what is right.
When looking at the above it should be able to check its metadata and
see that GMNR is a String, and construct the appropriate SQL.
Can you submit a bug report, with your example above. I will be able to
look at it after the 20th, but you may be able to ask Marc or Chris for
an earlier fix.
Ways to speed up the process:
- create a test cases to go with your bug report
- submit a patch :-)
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)
It is related, but the problem is really that the SQL generator needs to
pay attention to what it is doing.
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?
You would simply have to drop a new oracle datastore jar into your
geoserver install, just like what happened with postgis last week.
I already posted this one in geoserver-devel and Dave gave me the
advice to cross-post it here.
Good man Dave :-)
Any hint welcome - thanks in advance,
Hope this helps,
Jody
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
