+1, old QP should not be deprecated. Since the new one is in contrib,
it should just be stated that it doesn't necessarily have the same
back compat. issues as core, either that or it is marked as
experimental.
-Grant
On Aug 11, 2009, at 1:54 PM, Mark Miller wrote:
I don't think we should stick with the current path of replacing the
current QueryParser with the new contrib QueryParser in Lucene 3.0.
The new QueryParser has not been used much at all yet. Its
interfaces (which will need to abide by back compat in core) have
not been vetted enough.
The new parser appears to add complication to some of things that
were very simple with the old parser.
The main benefits of the new parser are claimed to be the ability to
plug and play many syntaxes and QueryBuilders. This is not an end
user benefit though and I'm not even sure how much of a benefit it
is to us. There is currently only one impl. It seems to me, once you
start another impl, its a long shot that the exact same query tree
representation is going to work with a completely different syntax.
Sure, if you are just doing postfix rather than prefix, it will be
fine – but the stuff that would likely be done – actual new syntaxes
– are not likely to be very pluggable. If a syntax can map to the
same query tree, I think we would likely stick to a single syntax –
else suffer the confusion and maintenance headaches for syntactic
sugar. More than a well factored QueryParser that can more easily
allow different syntaxes to map to the same query tree
representation, I think we just want a single solid syntax for core
Lucene that supports Spans to some degree. We basically have that
now, sans the spans support. Other, more exotic QueryParsers should
live in contrib, as they do now.
Which isn't to say this QueryParser should not one day rule the
roost – but I don't think its earned the right yet. And I don't
think there is a hurry to toss the old parser.
Personally, I think that the old parser should not be deprecated.
Lets let the new parser breath in contrib for a bit. Lets see if
anyone actually adds any other syntaxes. Lets see if the
pluggability results in any improvements. Lets see if some of the
harder things to do (overriding query build methods?) become easier
or keep people from using the new parser.
Lets just see if the new parser draws users without us forcing them
to it. And lets also wait and see what other committers say – not
many have gotten much time to deal with the new parser, or deal with
user list questions on it.
I just think its premature to start moving people to this new
parser. It didn't even really get in until right before release –
the paint on the thing still reeks. There is no rush. I saw we
undeprecate the current QueryParser and remove the wording in the
new QueryParser about it replacing the new in 3.0. Later, if we
think it should replace it (after having some experience to judge
from), we can reinstate the current plan. Anyone agree?
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
