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
<luc...@mikemccandless.com <mailto:luc...@mikemccandless.com>> wrote:
+1
Mike
On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch<busch...@gmail.com
<mailto:busch...@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: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>
>>
>>>
>>> -----Original Message-----
>>> From: Grant Ingersoll [mailto:gsing...@apache.org
<mailto:gsing...@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-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
>>>> For additional commands, e-mail:
java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
>>>>
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
>>> For additional commands, e-mail:
java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
>>>
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail:
java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
>>
>>
>>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
For additional commands, e-mail: java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
--
- 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
