It's an idea - sorry I don't have an implementation I can share easily;
it's embedded in our application code and not easy to refactor. I'm not
sure where this would fit in the solr architecture; maybe some subclass
of SearchHandler? I guess the query rewriter would need to be aware of
which parser it's trying to avoid errors in. In our case, we have a
limited case where we always use a single parser, but I think solr
exposes a pluggable extensible architecture with a lot of different
parsers, so a more general solution will be more complex, and I don't
have it :)
-Mike
On 05/05/2011 10:00 AM, Bernd Fehling wrote:
Hi Michael
sounds excellent to me.
Is it a QParserPlugin or what is it?
Regards
Bernd
Am 05.05.2011 14:05, schrieb Michael Sokolov:
In our applications, we catch ParseException and then take one of the
following actions:
1) report an error to the user
2) rewrite the query, stripping all punctuation, and try again
3) rewrite the query, quoting all punctuation, and try again
would that work for you?
On 5/5/2011 3:26 AM, Bernd Fehling wrote:
Dear list,
I need a QueryValidator and don't mind writing one but don't want
to reinvent the wheel in case there is already something.
Is this the right list for talking about a QueryValidator or
should it belong to SOLR?
What do I mean with a QueryValidator?
I think about something like validating the query before or after
parsing it.
Currently invalid queries [e.g. text:(:foo AND bar) ] throw exceptions
which pop up to the top. Not only that they show up in the logs
(which is good) they also give unuseful result page to jetty (which
is bad).
And they also waste time for searching what can't be searched.
What should the QueryValidator do?
- check the query against the searchable fields of the schema
(validate it)
- give options of fallback strategies
-- let it through as raw
-- remove specific chars (e.g. all ":" which have not a valid search
field before)
-- ...
- in case of an invalid query don't try to start a search but give a
clean no-hit-page
with a status and the cause
Actually it must be located somewhere around the parser.
What do think of this?
Regards,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
