You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Roman Chyla <ro...@gmail.com> on 2013/04/17 03:44:26 UTC
Why filter query doesn't use the same query parser as the main query?
Hi,
Is there some profound reason why the defType is not passed onto the filter
query?
Both query and filterQuery are created inside the QueryComponent, however
differently:
QParser parser = QParser.getParser(rb.getQueryString(), defType, req);
QParser fqp = QParser.getParser(fq, null, req);
So the filter query parser will default to 'lucene' and besides local
params such as '{!regex}' the only way to force solr to use a different
parser is to override the lucene query parser in the solrconfig.xml
<queryParser name="lucene" class="solr.SomeOtherQParserPlugin" />
That doesn't seem right. Are there other options I missed?
If not, should the defType be passed to instantiate fqp?
Thanks,
roman
Re: Why filter query doesn't use the same query parser as the main query?
Posted by Erik Hatcher <er...@gmail.com>.
True, you cannot currently specify a default (other than the trick Roman showed earlier) query parser for fq parameters. I think of the bulk of my fq's in the form of fq={!term f=facet_field}value so setting a default term query parser for fq's wouldn't really help me exactly, as it needs an f(ield) parameter specified uniquely for every fq. And then there's the key/excl stuff that I'm increasingly see folks use for faceting and filtering so that fq's on average are usually pretty complex entities. I'm not sure what a default fq query parser provides as a benefit to projects, so I'd love some examples. If there were a "field_term" qparser that took field:value syntax and didn't require any other per-instance parameterization such that it split by first colon and created a TermQuery that'd be handy. But with multiselect faceting, you're specifying an OR'd list of selections anyway and thus want a query parser that can do that too.
Erik
On Apr 17, 2013, at 13:25 , Upayavira wrote:
> You specify it as a default parameter for a requestHandler in your
> solrconfig.xml, giving a default value for defType. Not sure that you
> can set a default that will cover filter queries too.
>
> Upayavira
>
> On Wed, Apr 17, 2013, at 05:46 PM, Roman Chyla wrote:
>> Makes sense, thanks. One more question. Shouldn't there be a mechanism to
>> define a default query parser?
>>
>> something like (inside QParserPlugin):
>>
>> public static String DEFAULT_QTYPE = "default"; // now it
>> is LuceneQParserPlugin.NAME;
>>
>> public static final Object[] standardPlugins = {
>> DEFAULT_QTYPE, LuceneQParserPlugin.class,
>> LuceneQParserPlugin.NAME, LuceneQParserPlugin.class,
>> ...
>> }
>>
>> in this way we can use solrconfig.xml to override the default qparser
>>
>> Or does that break some assumptions?
>>
>> roman
>>
>>
>>
>> On Wed, Apr 17, 2013 at 8:34 AM, Yonik Seeley <yo...@lucidworks.com>
>> wrote:
>>
>>> On Tue, Apr 16, 2013 at 9:44 PM, Roman Chyla <ro...@gmail.com>
>>> wrote:
>>>> Is there some profound reason why the defType is not passed onto the
>>> filter
>>>> query?
>>>
>>> defType is a convenience so that the main query parameter "q" can
>>> directly be the user query (without specifying it's type like
>>> "edismax").
>>> Filter queries are normally machine generated.
>>>
>>> -Yonik
>>> http://lucidworks.com
>>>
Re: Why filter query doesn't use the same query parser as the main
query?
Posted by Upayavira <uv...@odoko.co.uk>.
You specify it as a default parameter for a requestHandler in your
solrconfig.xml, giving a default value for defType. Not sure that you
can set a default that will cover filter queries too.
Upayavira
On Wed, Apr 17, 2013, at 05:46 PM, Roman Chyla wrote:
> Makes sense, thanks. One more question. Shouldn't there be a mechanism to
> define a default query parser?
>
> something like (inside QParserPlugin):
>
> public static String DEFAULT_QTYPE = "default"; // now it
> is LuceneQParserPlugin.NAME;
>
> public static final Object[] standardPlugins = {
> DEFAULT_QTYPE, LuceneQParserPlugin.class,
> LuceneQParserPlugin.NAME, LuceneQParserPlugin.class,
> ...
> }
>
> in this way we can use solrconfig.xml to override the default qparser
>
> Or does that break some assumptions?
>
> roman
>
>
>
> On Wed, Apr 17, 2013 at 8:34 AM, Yonik Seeley <yo...@lucidworks.com>
> wrote:
>
> > On Tue, Apr 16, 2013 at 9:44 PM, Roman Chyla <ro...@gmail.com>
> > wrote:
> > > Is there some profound reason why the defType is not passed onto the
> > filter
> > > query?
> >
> > defType is a convenience so that the main query parameter "q" can
> > directly be the user query (without specifying it's type like
> > "edismax").
> > Filter queries are normally machine generated.
> >
> > -Yonik
> > http://lucidworks.com
> >
Re: Why filter query doesn't use the same query parser as the main query?
Posted by Roman Chyla <ro...@gmail.com>.
Makes sense, thanks. One more question. Shouldn't there be a mechanism to
define a default query parser?
something like (inside QParserPlugin):
public static String DEFAULT_QTYPE = "default"; // now it
is LuceneQParserPlugin.NAME;
public static final Object[] standardPlugins = {
DEFAULT_QTYPE, LuceneQParserPlugin.class,
LuceneQParserPlugin.NAME, LuceneQParserPlugin.class,
...
}
in this way we can use solrconfig.xml to override the default qparser
Or does that break some assumptions?
roman
On Wed, Apr 17, 2013 at 8:34 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> On Tue, Apr 16, 2013 at 9:44 PM, Roman Chyla <ro...@gmail.com>
> wrote:
> > Is there some profound reason why the defType is not passed onto the
> filter
> > query?
>
> defType is a convenience so that the main query parameter "q" can
> directly be the user query (without specifying it's type like
> "edismax").
> Filter queries are normally machine generated.
>
> -Yonik
> http://lucidworks.com
>
Re: Why filter query doesn't use the same query parser as the main query?
Posted by Yonik Seeley <yo...@lucidworks.com>.
On Tue, Apr 16, 2013 at 9:44 PM, Roman Chyla <ro...@gmail.com> wrote:
> Is there some profound reason why the defType is not passed onto the filter
> query?
defType is a convenience so that the main query parameter "q" can
directly be the user query (without specifying it's type like
"edismax").
Filter queries are normally machine generated.
-Yonik
http://lucidworks.com