lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-4271) Solr LocalParams for Lucene Query Parser
Date Sun, 18 Nov 2012 00:14:12 GMT

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

Chris Male commented on LUCENE-4271:
------------------------------------

{quote}
I think it's odd to add syntax to Lucene's query parser that does ... nothing?

And it's strange to make Lucene's QP aware of Solr QP's syntax if it cannot do anything with
it. It seems like Solr's QP should have this logic instead ...
{quote}

+1 

{quote}
Indeed - but it requires changes to the parser grammar, so subclassing doesn't cut it.
I suppose the next best thing would be to make a QP specific to Solr.
{quote}

I don't think we should consider that a bad thing.  Solr has different needs and the classic
QP is sort of the lowest common denominator of parsers.

bq. I don't mean to suggest that the Lucene Query Parser should know directly about the Solr-level
structures such as the Solr schema, Solr "params", and Solr Q Parser plugins, but I am suggesting
that Lucene could declare and support abstractions for those sorts of interfaces

I don't think we can practical extend the classic QP in every way just to meet Solr's needs.
 

bq. There are lots of useful features which are available in the Solr query parsers which
are unavailable directly to Lucene apps without a lot of effort, and for no good reason.

.. then the Lucene apps should use the Solr QPs or a version there of.  The Classic QP was
moved out of Lucene core for many reasons, but one was to combat this perspective that its
'the' QP when it is in fact just one particular implementation (an implementation which has
lots of limitations).  Users should be encouraged to use whatever QP meets their needs and
we shouldn't make the classic QP a kitchen sink.

bq. The current "estrangement" between the Lucene and Solr query parsers is quite a black
eye for Lucene/Solr that can easily be remedied, at least from a technical perspective.

I think we should go further and fully divorce them.  Solr has its needs and the handling
of LocalParams clearly seems to be confusing users but it isn't something the classic QP should
have to resolve.  Equally, Solr development shouldn't be saddled with having to compromise
its query features just so they fit into the classic QP.  As I say, the classic QP is the
lowest common denominator of query syntax and parsing and I would recommend to any user (Solr
or not) that when they need to make a large syntactical change, that they roll their own parser.
                
> Solr LocalParams for Lucene Query Parser
> ----------------------------------------
>
>                 Key: LUCENE-4271
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4271
>             Project: Lucene - Core
>          Issue Type: New Feature
>            Reporter: Yonik Seeley
>         Attachments: LUCENE-4271.patch
>
>
> The Lucene QueryParser should implement Solr's LocalParams syntax directly so that instead
of
> {code}
> _query_:"{!geodist d=10 p=20.5,30.2}"
> {code}
> one could directly use
> {code}
> {!geodist d=10 p=20.5,30.2}
>  {code}
> references: http://wiki.apache.org/solr/LocalParams

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


Mime
View raw message