Set the q.op parameter to OR and set mm=10% or something like that. The idea is 
to not excessively restrict the documents that will match, but weight the 
matched results based on how many word pairs and triples do match.

In addition, use the pf parameter to provide extra weight when the full query 
term phrase matches exactly.

-- Jack Krupansky

From: Nils Kaiser 
Sent: Friday, April 4, 2014 10:10 AM
To: solr-user@lucene.apache.org 
Subject: Strange behavior of edismax and mm=0 with long queries (bug?)

Hey, 

I am currently using solr to recognize songs and people from a list of user 
comments. My index stores the titles of the songs. At the moment my application 
builds word ngrams and fires a search with that query, which works well but is 
quite inefficient.

So my thought was to simply use the collated comments as query. So it is a case 
where the query is much longer. I need to use mm=0 or mm=1.

My plan was to use edismax as the pf2 and pf3 parameters should work well for 
my usecase.

However when using longer queries, I get a strange behavior which can be seen 
in debugQuery.

Here is an example:

Collated Comments (used as query)

"I love Henry so much. It is hard to tear your eyes away from Maria, but watch 
just his feet. You'll be amazed.
sometimes pure skill can will a comp, sometimes pure joy can win... put them 
both together and there is no competition
This video clip makes me smile.
Pure joy!
so good!
Who's the person that gave this a thumbs down?!? This is one of the best 
routines I've ever seen. Period. And it's a competitionl! How is that possible? 
They're so good it boggles my mind.
It's gorgeous. Flawless victory.
Great number! Does anybody know the name of the piece?
I believe it's called Sunny side of the street
Maria is like, the best 'follow' I've ever seen. She's so amazing.
Thanks so much Johnathan!"

Song name in Index
Louis Armstrong - Sunny Side of The Street

parsedquery_toString:
+(((text:I) (text:love) (text:Henry) (text:so) (text:much.) (text:It) (text:is) 
(text:hard) (text:to) (text:tear) (text:your) (text:eyes) (text:away) 
(text:from) (text:Maria,) (text:but) (text:watch) (text:just) (text:his) 
(text:feet.) (text:You'll) (text:be) (text:amazed.) (text:sometimes) 
(text:pure) (text:skill) (text:can) (text:will) (text:a) (text:comp,) 
(text:sometimes) (text:pure) (text:joy) (text:can) (text:win...) (text:put) 
(text:them) (text:both) +(text:together) +(text:there) (text:is) (text:no) 
(text:competition) (text:This) (text:video) (text:clip) (text:makes) (text:me) 
(text:smile.) (text:Pure) (text:joy!) (text:so) (text:good!) (text:Who's) 
(text:the) (text:person) (text:that) (text:gave) (text:this) (text:a) 
(text:thumbs) (text:down?!?) (text:This) (text:is) (text:one) (text:of) 
(text:the) (text:best) (text:routines) (text:I've) (text:ever) (text:seen.) 
+(text:Period.) +(text:it's) (text:a) (text:competitionl!) (text:How) (text:is) 
(text:that) (text:possible?) (text:They're) (text:so) (text:good) (text:it) 
(text:boggles) (text:my) (text:mind.) (text:It's) (text:gorgeous.) 
(text:Flawless) (text:victory.) (text:Great) (text:number!) (text:Does) 
(text:anybody) (text:know) (text:the) (text:name) (text:of) (text:the) 
(text:piece?) (text:I) (text:believe) (text:it's) (text:called) (text:Sunny) 
(text:side) (text:of) (text:the) (text:street) (text:Maria) (text:is) 
(text:like,) (text:the) (text:best) (text:'follow') (text:I've) (text:ever) 
(text:seen.) (text:She's) (text:so) (text:amazing.) (text:Thanks) (text:so) 
(text:much) (text:Johnathan!))~1)</str>
 
This query generates 0 results. The reason is it expects terms together, there, 
Period., it's to be part of the document (see parsedquery above, all other 
terms are optional, those terms are must).

Is there any reason for this behavior? If I use shorter queries it works 
flawlessly and returns the document.

I've appended the whole query.

Best,

Nils

Reply via email to