Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1994220575.1254978451280.JavaMail.jira@brutus>
Date: Wed, 7 Oct 2009 22:07:31 -0700 (PDT)
From: "Adriano Crestani (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1938) Precedence query parser using the
 contrib/queryparser framework
In-Reply-To: <951890738.1254438143770.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763365#action_12763365 ] 

Adriano Crestani commented on LUCENE-1938:
------------------------------------------

{quote}
I looked at the pipeline PrecedenceQueryNodeProcessorPipeline, it contains some complex logic off removing a processor from the StandardQueryNodeProcessorPipeline.

I think it would be better to have a common ancestor, CommonQueryNodeProcessorPipeline, that both StandardQueryNodeProcessorPipeline and PrecedenceQueryNodeProcessorPipeline can extend.
{quote}

I don't think it's so complex, it just removes GroupQueryNodeProcessor and adds ModifierQueryNodeProcessor (I think this is the class name). I also added this description to the javadocs.

Anyway, I would prefer to leave it like that, extending StandardQPP, instead of creating a common pipeline. The common pipeline would not make much sense right now, there is not QueryBuilder impl that would produce a correct Query instance from a query tree processed by it, so no one could just use it.

In future, we could have a third QP implementation, that instead of replacing GroupQueryNodeProcessor by ModifierQueryNodeProcessor, it would replace another processor, or switch the processors position, etc... the CommonQueryNodeProcessorPipeline would not make sense anymore, it only make sense right now for PrecedenceQP and StandardQP, because we know what both have in common, but doesn't mean a third QP would have the same in common.

So, +1 to leave it the way it's.


> Precedence query parser using the contrib/queryparser framework
> ---------------------------------------------------------------
>
>                 Key: LUCENE-1938
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1938
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: contrib/*
>    Affects Versions: 2.9
>            Reporter: Adriano Crestani
>            Assignee: Adriano Crestani
>            Priority: Minor
>             Fix For: 3.1
>
>         Attachments: LUCENE-1938.patch
>
>
> Extend the current StandardQueryParser on contrib so it supports boolean precedence

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org