You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael McCandless <lu...@mikemccandless.com> on 2009/08/12 00:03:04 UTC
Re: The new Contrib QueryParser should not be slated to replace the
old one yet
+1
Mike
On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch<bu...@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
Re: The new Contrib QueryParser should not be slated to replace the
old one yet
Posted by Mark Miller <ma...@gmail.com>.
Hey Shai - I'm not saying if new syntax's come lets use it. Sorry if it
came off that way - I'm basically saying - lets see it get used - lets
see if the things that it offers are taken advantage of. A new syntax is
not a plus to me necessarily (though it is nice) - personally, I just
want a solid core syntax for Lucene, and I think the rest is gravy. But
because the new QP is billed as easy to develop new syntaxs for (in the
package.html I think), I'm just saying, lets see how the thing turns
out. I don't mean to really pin point any one thing in that regard - we
should just let it breath, and then take stalk again.
Basically I just think we should give it a little time. I only wrote out
so much, and tried to come up with points like that, because an early
short comment went ignored ;)
- Mark
Shai Erera wrote:
> 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 <ma...@mikemccandless.com>> wrote:
>
> +1
>
> Mike
>
> On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch<buschmic@gmail.com
> <ma...@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 <ma...@thetaphi.de>
> >>
> >>
> >>>
> >>> -----Original Message-----
> >>> From: Grant Ingersoll [mailto:gsingers@apache.org
> <ma...@apache.org>]
> >>> Sent: Tuesday, August 11, 2009 8:32 PM
> >>> To: java-dev@lucene.apache.org <ma...@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
> <ma...@lucene.apache.org>
> >>>> For additional commands, e-mail:
> java-dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
> >>>>
> >>>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> >>> For additional commands, e-mail:
> java-dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
> >>>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> >> For additional commands, e-mail:
> java-dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
> >>
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> For additional commands, e-mail: java-dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
>
>
--
- 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
Re: The new Contrib QueryParser should not be slated to replace the
old one yet
Posted by Shai Erera <se...@gmail.com>.
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<bu...@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
>
>