On Thursday 02 August 2007 20:18, Walter Underwood wrote:
> I agree about the fussiness and mystery of good values for minimum
> match, but the requestor wanted 100% all the time. That is easy.
But I want it only by default, with an easy way to go back to OR for parts
of the query, e.g. doing a
I agree about the fussiness and mystery of good values for minimum match,
but the requestor wanted 100% all the time. That is easy.
I think spell suggestions are harder than search, so "assume great spell
suggestions" is not a good fix for a bad default (all terms).
wunder
On 8/2/07 11:13 AM, "
-Original Message-
From: Kevin Holmes [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 02, 2007 1:58 PM
To: solr-user@lucene.apache.org
Subject: RE: Error when starting Solr using Tomcat V6 (tomcat6-6.0.13)
What's the command you are using to start solr?
I'm running it from a script,
On Thursday 02 August 2007 18:46, Walter Underwood wrote:
> Use the minimum match spec for a flexible version of all-terms
> matching.
I think this is too difficult and unpredictable. I also don't know how I
should justify a setting like "75%", just because it maybe works fine for
some examples
What's the command you are using to start solr?
Hi,
I'm getting the follwing error when starting Solr:
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoade
On 8/1/07, Stu Hood <[EMAIL PROTECTED]> wrote:
> I've been using Solr in an embedded situation, and its been working quite
> well. But as I've started scaling up the application, the logging that Solr
> does to stderr is getting excessive.
>
> I'd like to disable the INFO messages, and leave the
Use the minimum match spec for a flexible version of all-terms
matching.
Before implementing all-terms matching, start logging the number of
searches that result in no matches. All-terms can cause big problems.
One wrong or misspelled word means no matches, and searchers don't
know how to fix the
Chris Hostetter wrote:
: :
: : text^0.5 features^1.0 name^1.2 manu^1.1
: :
: > if the q param is: albino elephant ... what would it mean that text and
: > feature are mandatory? do both words have to appear in text and in
: > feature, or just one in each?
: What I wanted
I realize you've fixed the problem by replacing "and" with "&&" but it's
worthwhile to note that boolean operators in lucene are case-sensitive, you
must use uppercase "AND" and "OR" in your query for it to work properly.
cheers,
Piete
On 02/08/07, sammael <[EMAIL PROTECTED]> wrote:
>
>
> post.
Thanks Yonik.
Noted and fixed. I'll take extra care with this scenarios.
Regards,
Daniel
On 1/8/07 20:08, "Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> On 8/1/07, Daniel Alheiros <[EMAIL PROTECTED]> wrote:
>> I'm using the PorterStemmerFilterFactory when indexing but not when
>> querying.
>
>
sorry carefully read lucen syntax manual
use && instead and all works fine now
--
View this message in context:
http://www.nabble.com/why-solr-and-clause-not-working-tf4204987.html#a11961242
Sent from the Solr - User mailing list archive at Nabble.com.
post.addParameter("q","(post_date:[118598900 TO *])and(catregory_id:2)");
returned result contains category_id ==1
also in the case of
post.addParameter("q","(post_date:[118598900 TO *])");
post.addParameter("qf","((forum_id:1 forum_id:2)and(category_id:2)");
returned result contains ca
13 matches
Mail list logo
