Brian,
Thanks for the great job with the query parser. I tested it and didn't find
any problem for the kind of queries we do. It's great term boosting API is
now exposed to the query parser.
As for the field specific analyzer, the first option is what would comply
better with the "principle of commensurate effort" that you mention. It
would make our job much easier. So I am voting +1 for option one. I am
willing to wait longer for a more elegant solution.
Is there a plan for a better optimized version of the stemmer? Haven't hit
any performance issue yet but I was wondering about production load.
Cheers,
Alex Murzaku
-----Original Message-----
1 (complicated way): When the index store is created, register an
analyzer for each field (could be the same one.) A serialized copy of
the analyzer is stored in the index base, and queries on that field
are automatically processed with it.
2 (simpler, less complete way): Have a way of telling the query parser
that "these fields use these analyzers", or at the very least, "these
fields don't get tokenized with an analyzer."
_______________________________________________
Lucene-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/lucene-dev
