Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Mon, 6 Feb 2012 02:43:59 +0000 (UTC)
From: "Mike (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <351462073.637.1328496239376.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1142883636.28976.1326263799312.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-3028) Support for additional query
 operators (feature parity request)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Mike commented on SOLR-3028:
----------------------------

Agreed - now that we're talking through three threads simultaneously, it seems obvious we need three tickets. This one can serve as a meta ticket, I suppose.

Therefore:
1. I split off *exact match* into SOLR-3099, and made a comment in SOLR-2866. I think they're different enough to warrant separate issues.
2. I split off *quorum search* into SOLR-3100.
3. I split off *word order* to issue SOLR-3101..

And I'll set depends on flags shortly here, assuming I have the needed permissions. Thanks again for the guidance and help, Hoss.
                
> Support for additional query operators (feature parity request)
> ---------------------------------------------------------------
>
>                 Key: SOLR-3028
>                 URL: https://issues.apache.org/jira/browse/SOLR-3028
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>    Affects Versions: 4.0
>            Reporter: Mike
>              Labels: operator, queryparser
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> I'm migrating my system from Sphinx Search, and there are a couple of operators that are not available to Solr, which are available in Sphinx. 
> I would love to see the following added to the Dismax parser:
> 1. Exact match. This might be tricky to get right, since it requires work on the index side as well[1], but in Sphinx, you can do a query such as [ =running walking ], and running will have stemming off, while walking will have it on. 
> 2. Term quorum. In Sphinx and some commercial search engines (like Recommind, Westlaw and Lexis), you can do a search such as [ (cat dog goat)/15 ], and find the three words within 15 terms of each other. I think this is possible in the backend via the span query, but there's no front end option for it, so it's quite hard to reveal to users.
> 3. Word order. Being able to say, "this term before that one, and this other term before the next" is something else in Sphinx that span queries support, but is missing in the query parser. Would be great to get this in too.
> These seem like the three biggest missing operators in Solr to me. I would love to help move these forward if there is any way I can help.
> [1] At least, *I* think it does. There's some discussion of one way of doing exact match like support in SOLR-2866.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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