Jürgen,
This is a side-effect of how the Expression parser works. It really
needs to be much more aware of the schema its interacting with.
The original implementors looked at <Literal> elements and said "if this
looks like a number, then treat it like a number". Unfortunately, this
is a problem if your string looks like a number. Expression should
probably re-work itself based on the schema (FeatureType) its actually
querying against.
Re-working Expression and Filter is probably too much work for right
now, but you can probably easily change the JDBC Datastore so if you do
a query like yours correctly.
Ie. <DB VARCHAR col> = <Number> gets converted to <DB VARCHAR col> =
<Number converted to a String>. This will not work 100% of the time,
but it should work most of the time.
dave
ps. here's an example where it will not work:
..
<Literal>
0.5678567567567856785678456789456789456789456789567894567895678
</Literal>
When this is converted to a Double, you cannot re-convert it to the
original string.
dave
----------------
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?
Any hint welcome - thanks in advance,
Jürgen
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/