Hi list,
using OCI featureTypes Geoserver/Geotools always adds an UPPER function to
the SQL clause, which results in a case-insensitive search by default.
But when using ArcSDE featureTypes, the search is case-sensitive ...
Is case-insensitive search implemented for ArcSDE?
If so, do we need to use the matchCase attribute from Filter 1.1?
Best regards,
Bart
--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl
Bart van den Eijnden (OSGIS) ha scritto:
Hi list,
using OCI featureTypes Geoserver/Geotools always adds an UPPER function to
the SQL clause, which results in a case-insensitive search by default.
Hum, this has been an implementation detail for the Oracle data store,
but I'm not sure it's OGC filter compliant. It should probably be turned
into a datastore hint.
But when using ArcSDE featureTypes, the search is case-sensitive ...
Is case-insensitive search implemented for ArcSDE?
If so, do we need to use the matchCase attribute from Filter 1.1?
Theoretically yes, but a quick investigation in the source code
seems to suggest none of the jdbc based datastores is respecting
the matchCase... ah, but wait, I looked into the oracle data store
and the only UPPERCASE I see is for like comparisons...
The Filter 1.1 spec states:
"The Common Catalog Query Language [4] defines a standard set of comparison operators (=,<,>,>=,<=,<>). These comparison operators are encoded using the complex type BinaryComparisonOpType. This type definition includes the matchCase attribute which is of type Boolean and controls whether string comparisons are caseless or not. A value of true means that string comparisons also match case. This is the default value. A value of false means that string comparisons are performed caselessly."
As you can see, Like is not among the lot, and in fact there is no
isMatchCase attribute for that element.
Yet, the PropertyIsLike definition is simply:
"The <PropertyIsLike> element is intended to encode a character string comparison operator with pattern matching. The pattern is defined by a combination of regular characters, the wildCard character, the singleChar character, and the escapeChar character. The wildCard character matches zero or more characters. The singleChar character matches exactly one character. The escapeChar character is used to escape the meaning of the wildCard, singleChar and escapeChar itself."
Nothing about case sensitiveness. I believe the spec is oriented
towards case sensitive comparisons, but it does not really state anything about that. Gonna ask on wfs-dev OGC mailing list.
Given that the spec left a hole, and that there is no way to ask
either way within the request, I'd say we could allow admin
to control this behaviour at the datastore level, with the risk
of not being WFS compliant anymore (rationale, the postgis datastore we use for cite compliancy performs a case sensitive like comparison, and we're the reference implementation).
Gabriel, what do you think?
Cheers
Andrea
> Theoretically yes, but a quick investigation in the source code
seems to suggest none of the jdbc based datastores is respecting
the matchCase... ah, but wait, I looked into the oracle data store
and the only UPPERCASE I see is for like comparisons...
FYI, Postgis should be respecting the matchCase parameter. Its part of wfs 1.1 cite compliance.
Justin Deoliveira ha scritto:
> Theoretically yes, but a quick investigation in the source code
seems to suggest none of the jdbc based datastores is respecting
the matchCase... ah, but wait, I looked into the oracle data store
and the only UPPERCASE I see is for like comparisons...FYI, Postgis should be respecting the matchCase parameter. Its part of wfs 1.1 cite compliance.
Really? Doh, I looked into Postgis sql encoder with the wrong search
key then... yeah, found it. It actually supports it. Thanks for the info.
Cheers
Andrea