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: [email protected]
For additional commands, e-mail: [email protected]
