lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MitchK <mitc...@web.de>
Subject Re: Minimum Should Match the other way round
Date Thu, 22 Apr 2010 13:04:44 GMT

Hi Hoss,

thank you for joining the discussion :).

2) If I understood the API-documentation right, the behaviour of the
FieldQParser depends exactly on what I've defined in my analyzer. 

3) This seems to be a very good solution. I don't come from the Lucene
corner and I started developing with Solr, so maybe some of my thoughts are
wrong. But as I understood, you would suggest the following:

Subclass e.g. LuceneQParser -> let's call the class LuceneLengthQParser

In the LuceneLengthQParser I instantiate a FieldQParser. This parser uses
some filters which I have defined in my titleLength-field to retrive the
QueryLength.
Now I can forward QueryLength to a setMaxLength(int QueryLength, int
increment)-method.
The returnValue can appended to the QueryString. Afterwards the original
LuceneQParser can do his job.

To make sure that people can extend every parser they like, I would like to
seperate the "rule-part" of my custom parser, so that they can easily extend
other parsers by including the length-retrival-part.
 
I think, if I understood everything right, I will subscribe to the developer
list and open an issue for that.

--
However, there are two another understanding - questions:
What does WDF mean and what does HTE stand for?

Thank you very much!

Kind regards
- Mitch
-- 
View this message in context: http://lucene.472066.n3.nabble.com/Minimum-Should-Match-the-other-way-round-tp694867p742797.html
Sent from the Solr - User mailing list archive at Nabble.com.

Mime
View raw message