You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by raikoe <lu...@keskus.de> on 2007/10/31 12:16:36 UTC

SolrQueryParser Default Operator from schema.xml broken in trunk?

Hello,

today i updated the solr libs in my application to the current trunk
version. It seems that the default operator (which i defined AND in my
schema.xml) is not considered anymore when creating the new SolrQueryParser
in LuceneQParserPlugin.java:66. In my query I do not define the default
operator as a local query parameter. Maybe a fallback to the globally
specified parameters is missing.
Is this overhaul from SOLR-334 still in the works or is this new behaviour
intended? 

Thanks in advance,
Raiko
-- 
View this message in context: http://www.nabble.com/SolrQueryParser-Default-Operator-from-schema.xml-broken-in-trunk--tf4724215.html#a13506821
Sent from the Solr - Dev mailing list archive at Nabble.com.


Re: SolrQueryParser Default Operator from schema.xml broken in trunk?

Posted by raikoe <lu...@keskus.de>.

Yonik Seeley wrote:
> 
> I think I've fixed it... can you try the latest trunk?
> 
> -Yonik
> 

Yes, now it works :)

Thanks for the quick fixing.
   Raiko
-- 
View this message in context: http://www.nabble.com/SolrQueryParser-Default-Operator-from-schema.xml-broken-in-trunk--tf4724215.html#a13511449
Sent from the Solr - Dev mailing list archive at Nabble.com.


Re: SolrQueryParser Default Operator from schema.xml broken in trunk?

Posted by Yonik Seeley <yo...@apache.org>.
On 10/31/07, raikoe <lu...@keskus.de> wrote:
> today i updated the solr libs in my application to the current trunk
> version. It seems that the default operator (which i defined AND in my
> schema.xml) is not considered anymore when creating the new SolrQueryParser
> in LuceneQParserPlugin.java:66. In my query I do not define the default
> operator as a local query parameter. Maybe a fallback to the globally
> specified parameters is missing.
> Is this overhaul from SOLR-334 still in the works or is this new behaviour
> intended?

I think I've fixed it... can you try the latest trunk?

-Yonik