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 Eric Wu <ei...@gmail.com> on 2012/08/30 09:12:56 UTC

lucene multi term query

Hi there,

    Here is what I want to do: I have some documents that contain two
fields, say "title" and "body", and they are both NOT stored. And now I
want the user to be able to search inside both "title" and "body" with some
keyword, say "lucene", using MultiTermQuery (I don't want to use two
separate queries because I might have a lot more fields that also need to
be searched). The problem is when the search is done, I want to know not
only which documents was hit, but also which field of each document was
hit. For example, some document has "lucene" in title but not in body, and
I need to know this when the search is done. And since the search is
possible without field be stored, so this kind of information must be
inside the index, but I cannot find any way to retrieve it. Maybe I miss
something here? Or could somebody please explain to me why is this not
possible? It seems like a very natural feature that we should have.

-- 
Ke Wu,
Best Regards

Re: lucene multi term query

Posted by Jack Krupansky <ja...@basetechnology.com>.
If you add the &debugQuery=true request option, the "explain" section of the 
response will have all of that info, and a lot more. That may be a lot to 
sift through, but at least it is there. You can identify each document and 
then check which field names appear in the scoring for that document.

-- Jack Krupansky

-----Original Message----- 
From: Eric Wu
Sent: Thursday, August 30, 2012 3:12 AM
To: solr-user@lucene.apache.org
Subject: lucene multi term query

Hi there,

    Here is what I want to do: I have some documents that contain two
fields, say "title" and "body", and they are both NOT stored. And now I
want the user to be able to search inside both "title" and "body" with some
keyword, say "lucene", using MultiTermQuery (I don't want to use two
separate queries because I might have a lot more fields that also need to
be searched). The problem is when the search is done, I want to know not
only which documents was hit, but also which field of each document was
hit. For example, some document has "lucene" in title but not in body, and
I need to know this when the search is done. And since the search is
possible without field be stored, so this kind of information must be
inside the index, but I cannot find any way to retrieve it. Maybe I miss
something here? Or could somebody please explain to me why is this not
possible? It seems like a very natural feature that we should have.

-- 
Ke Wu,
Best Regards 


Re: lucene multi term query

Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi Eric,

This is a common question :)
Here are some previous answers: http://search-lucene.com/?q=which+field+hit+match&fc_project=Solr

Otis 
----
Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm 



----- Original Message -----
> From: Eric Wu <ei...@gmail.com>
> To: solr-user@lucene.apache.org
> Cc: 
> Sent: Thursday, August 30, 2012 3:12 AM
> Subject: lucene multi term query
> 
> Hi there,
> 
>     Here is what I want to do: I have some documents that contain two
> fields, say "title" and "body", and they are both NOT 
> stored. And now I
> want the user to be able to search inside both "title" and 
> "body" with some
> keyword, say "lucene", using MultiTermQuery (I don't want to use 
> two
> separate queries because I might have a lot more fields that also need to
> be searched). The problem is when the search is done, I want to know not
> only which documents was hit, but also which field of each document was
> hit. For example, some document has "lucene" in title but not in body, 
> and
> I need to know this when the search is done. And since the search is
> possible without field be stored, so this kind of information must be
> inside the index, but I cannot find any way to retrieve it. Maybe I miss
> something here? Or could somebody please explain to me why is this not
> possible? It seems like a very natural feature that we should have.
> 
> -- 
> Ke Wu,
> Best Regards
>