Jody Garnett ha scritto: > 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
There is a jira with a simple idea: adding a ILIKE operator for case insensitive matches: http://jira.codehaus.org/browse/GEOT-2359 However it never got past the idea stage. > 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; Matching case is _not_ the default behavior. The opposite is. Look at the factory implementation, it will call the FilterFactory2 method pass false -> case insensitive. > - 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) I was wondering about the current sql translation. What is done for case insensitive filters (which is the only type we generate): upper(fieldname) like 'pattern' This could be expressed similarly using filter functions: strToUpperCase(fieldName) like 'pattern' However there is a catch, the above is not valid CQL (not sure if it's valid ECQL either). But it can be expressed in OGC filter. There is the catch that sql encoders won't recognize the function call as encodable so we'd end up running the filter in memory, but that can be fixed Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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
