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.
