On Feb 19, 2005, at 3:52 AM, Paul Elschot wrote:
By lowercasing the querytext and searching in title_lc ?
Well sure, but how about this query:
title:Something AND anotherField:someOtherValue
QueryParser, as-is, won't be able to do field-name swapping. I could certainly apply that technique on all the structured queries that I build up with the API, but with QueryParser it is trickier. I'm definitely open for suggestions on improving how case is handled. The
Overriding this (1.4.3 QueryParser.jj, line 286) might work:
protected Query getFieldQuery(String field, String queryText) throws ParseException { ... }
It will be called by the parser for both parts of the query above, so one
could change the field depending on the requested type of search
and the field name in the query.
But that wouldn't work for any other type of query.... title:somethingFuzzy~
Though now that I think more about it, a simple s/title:/title_orig:/ before parsing would work, and of course make the default field dynamic. I need to evaluate how many fields would need to be done this way - it'd be several. Thanks for the food for thought!
only drawback now is that I'm duplicating indexes, but that is only an
issue in how long it takes to rebuild the index from scratch (currently
about 20 minutes or so on a good day - when the machine isn't swamped).
Once the users get the hang of this, you might end up having to quadruple
the index, or more.
Why would that be? They want a case sensitive/insensitive switch. How would it expand beyond that?
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
