lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Wed, 12 Aug 2009 11:21:39 GMT
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 <mailto:lucene@mikemccandless.com>> wrote:
>
>     +1
>
>     Mike
>
>     On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch<buschmic@gmail.com
>     <mailto: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 <mailto:uwe@thetaphi.de>
>     >>
>     >>
>     >>>
>     >>> -----Original Message-----
>     >>> From: Grant Ingersoll [mailto:gsingers@apache.org
>     <mailto:gsingers@apache.org>]
>     >>> Sent: Tuesday, August 11, 2009 8:32 PM
>     >>> To: java-dev@lucene.apache.org <mailto: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
>     <mailto:java-dev-unsubscribe@lucene.apache.org>
>     >>>> For additional commands, e-mail:
>     java-dev-help@lucene.apache.org
>     <mailto:java-dev-help@lucene.apache.org>
>     >>>>
>     >>>>
>     >>>
>     >>>
>     ---------------------------------------------------------------------
>     >>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>     <mailto:java-dev-unsubscribe@lucene.apache.org>
>     >>> For additional commands, e-mail:
>     java-dev-help@lucene.apache.org
>     <mailto:java-dev-help@lucene.apache.org>
>     >>>
>     >>
>     >>
>     >>
>     ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>     <mailto:java-dev-unsubscribe@lucene.apache.org>
>     >> For additional commands, e-mail:
>     java-dev-help@lucene.apache.org
>     <mailto:java-dev-help@lucene.apache.org>
>     >>
>     >>
>     >>
>     >
>     >
>     >
>     ---------------------------------------------------------------------
>     > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>     <mailto:java-dev-unsubscribe@lucene.apache.org>
>     > For additional commands, e-mail: java-dev-help@lucene.apache.org
>     <mailto:java-dev-help@lucene.apache.org>
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>     <mailto:java-dev-unsubscribe@lucene.apache.org>
>     For additional commands, e-mail: java-dev-help@lucene.apache.org
>     <mailto:java-dev-help@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


Mime
View raw message