lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Wed, 12 Aug 2009 03:58:07 GMT
Mark,

I support not deprecating the current QP.

But I just wanted to comment on "let's wait 'till people add more syntaxes".
I don't think that that's the issue here. The new QP is indeed useful for
plugging in different search syntaxes, but I personally don't believe that
in an application more than one search syntax is used. If there are such,
then I'd think their number is very small. And, I agree w/ you - two
different syntaxes are not that likely to be able to reuse the same Query
tree etc.

However, the new QP, AFAIU, allows one to extend the Lucene syntax more
easily. And if some extension to Lucene's syntax is useful, why contribute
it as a contrib module and not augment the default QP?

So just contributing a new query syntax as a contrib module doesn't mean the
new QP should be used. In fact, I wrote a QP for a different syntax than
Lucene's, and I didn't use the new QP as base and it works just great. In
fact, my QP is quite simple, and does not involve building a query tree,
using builders etc.

And in general I think, writing your own QP for your own query syntax is a
super advanced thing, which only few do. So this QP will benefit the
minority of Lucene users / developers, IMO.

So I'm not sure that waiting for users to contribute more syntaxes is what
we need in order to decide whether this QP should replace the old one. We're
more likely to see users experiencing problems w/ it (just because it's new
and hasn't been used in the field much yet) in the near future.

This QP currently looks like an OOD exercise. If there will be more syntaxes
contributed, then it wins. Otherwise, it's just s rewrite of the old QP, and
we need to be sure that the rewrite is worth it.

Shai

On Wed, Aug 12, 2009 at 1:03 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:

> +1
>
> Mike
>
> On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch<buschmic@gmail.com> wrote:
> > I agree we should not remove the old one in 3.0. That's way too early.
> > If we change the bw-policy we can replace it maybe in 3.1.
> >
> > On 8/11/09 11:40 AM, Uwe Schindler wrote:
> >>
> >> Yes, we should not deprecate the old one!
> >>
> >> -----
> >> Uwe Schindler
> >> H.-H.-Meier-Allee 63, D-28213 Bremen
> >> http://www.thetaphi.de
> >> eMail: uwe@thetaphi.de
> >>
> >>
> >>>
> >>> -----Original Message-----
> >>> From: Grant Ingersoll [mailto:gsingers@apache.org]
> >>> Sent: Tuesday, August 11, 2009 8:32 PM
> >>> To: java-dev@lucene.apache.org
> >>> Subject: Re: The new Contrib QueryParser should not be slated to
> replace
> >>> the old one yet
> >>>
> >>> +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-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: java-dev-help@lucene.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-dev-help@lucene.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

Mime
View raw message