So we kind of have three things going on: - Our Filter interfaces support both case sensitive and case insensitive behaviour for all comparison operations and like filter - The Filter 1.1 specification screwed up and forgot a matchCase for Like; everything else is covered - Our CQL / ECQL parser/encoders just use the default behavior; and do not provide any switch to enable control of the matchCase clause
I think the first thing is to get control in the hands of the people :-) Can CQL/ECQL be updated with a matchCase of some description? - option 1: update the ECQL syntax (this is actually a bit scary and I am not sure I want to go there) - option 2: CQL supports a user supplied FilterFactory; allow your FIlterFactory to be configured with a Hint controlling the default value of matchCase when it is not otherwise supplied - option 3: update the CQL api to support toFilter( String cql, boolean matchCase ) which would be a short hand for the FilterFactory as mentioned above - option 4: make a filter visitor that returns a copy of the provided filter with matchCase toggled to the value provided right across the board As for a default value of match case: - Matching case is the current default behaviour and I don't think it is a bad default for most comparison operations; - We run into trouble with "LIKE" since it is often used as a poor mans full text search engine replacement (as such case insensitive is expected) If we want to be kind we should have a Hint.FILTER_MATCH_CASE with a default value of null; when not specified comparison operations can be case-sensitive; like can be case insensitive; if provided the hint value can be used. Jody On 17/06/2010, at 2:43 PM, christian.muel...@nvoe.at wrote: > I can remember this discussion since I think I pointed out the problem > with the indices. And I was against it. > > I am wondering that this feature is implemented. Nobody, having a > little knowledge about db engines would formulate such an SQL clause > putting performance for large tables into the cellar. It is better to > store the uppercase content into an additional attribute. > > Anyways, I see some questions on the user lists like > > "Why is the performance so slow.... " > > and then we have to inform the user to not use this feature, but we > are offering it. Strange. > > > > Quoting Justin Deoliveira <jdeol...@opengeo.org>: > >> Yeah seems strange. Although something vaguely familiar perhaps for cite >> tests. But I can't recall anything that would require that behavior, I >> think case sensitive should be the default. >> >> On 10-06-16 11:12 AM, Andrea Aime wrote: >>> Hi, >>> the current filter factory creates case insensitive like filters >>> which end up being encoded in sql as upper(att) like 'BLAH%' >>> making it impossible to use indexing. >>> >>> Was that done on purpose or just by accident? >>> >>> Cheers >>> Andrea >>> >> >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
