RE: matching exact/whole phrase

[darniz <rn...@edmunds.com>]

Extending this thread.
Is it safe to say in order to do exact matches the field should be a string.
Let say for example i have two fields on is caption which is of type string
and the other is regular text.
So if i index caption as "my car is the best car in the world" it will be
stored and i copy the caption to the text field. Since text has all
anylysers defined so lets assume only the following words are indexed after
stop words and other filters "my", "car","best","world"

Now in my dismax handler if i have the qf defined as text field and run a
phrase search on text field
"my car is the best car in the world"
i dont get back any results. looking with debugQuery=on this is the
parsedQuery
text:"my tire pressure warning light came my honda civic"
This will not work since text was indexed by removing all stop words.
But if i remove the double quotes it matches that document.

Now if i add extra query field &qf=caption and then do a phrase search i get
back that document since caption is of type string and it maintains all the
stop words and other stuff.

Is my assumption correct.

After i get a response i will put some more questions.
Thanks
darniz








Sandeep Shetty-2 wrote:
> 
> That was the answer I was looking for, I will try that one out
> 
> Thanks Daniel
> 
> -----Original Message-----
> From: Daniel Papasian [mailto:daniel.papasian@chronicle.com]
> Sent: 01 April 2008 16:03
> To: solr-user@lucene.apache.org
> Subject: Re: matching exact/whole phrase
> 
> Sandeep Shetty wrote:
>> Hi people,
>>
>> I am looking to provide exact phrase match, along with the full text
>> search with solr.  I want to achieve the same effect in solr rather
>> than use a separate SQL query. I want to do the following as an
>> example
>>
>> The indexed field has the text "car repair" (without the double
>> quotes)  for a document and I want this document to come in the
>> search result only if someone searches for "car repair". The document
>> should not show up for "repair" and "car" searches.
>>
>> Is it possible to do this type of exact phrase matching if needed
>> with solr itself?
> 
> It sounds like you want to do an exact string match, and not a text
> match, so I don't think there's anything complex you'd need to do...
> just store the field with "car repair" as type="string" and do all of
> the literal searches you want.
> 
> But if you are working off a field that contains something beyond the
> exact match of what you want to search for, you'll just need to define a
> new field type and use only the analysis filters that you need, and
> you'll have to think more about what you need if that's the case.
> 
> Daniel
> 
> Sandeep Shetty
> Technical Development Manager
> 
> Touch Local
> 89 Albert Embankment, London, SE1 7TP, UK
> D: 020 7840 4335
> E: sandeep.shetty@touchlocal.com
> T: 020 7840 4300
> F: 020 7840 4301 
> 
> This email is confidential and may also be privileged. If you are not the
> intended recipient please notify us immediately by calling 020 7840 4300
> or email postmaster@touchlocal.com. You should not copy it or use it for
> any purpose nor disclose its contents to any other person. Touch Local Ltd
> cannot accept liability for statements made which are clearly the sender's
> own and are not made on behalf of the firm.
> Registered in England and Wales. Registration Number: 2885607 VAT Number:
> GB896112114
> 
> Help to save some trees. Print e-mails only if you really need to.
> 
> 

-- 
View this message in context: http://old.nabble.com/matching-exact-whole-phrase-tp16424969p27329651.html
Sent from the Solr - User mailing list archive at Nabble.com.

RE: matching exact/whole phrase

[Chris Hostetter <ho...@fucit.org>]

: Is it safe to say in order to do exact matches the field should be a string.

It depends on your definition of "exact"

If you want exact matches, including unicode codepoints and 
leading/trailing whitespace, then StrField would probably make sense -- 
but you could equally use TextField with a KeywrodTokenizer and nothing 
else.

If you want *some* normalization (ie: trim leading/trailing whitespace, 
map equivilent codepoints to a canonical representation, etc...) then you 
need TextyField.

: Now in my dismax handler if i have the qf defined as text field and run a
: phrase search on text field
: "my car is the best car in the world"
: i dont get back any results. looking with debugQuery=on this is the
: parsedQuery
: text:"my tire pressure warning light came my honda civic"
: This will not work since text was indexed by removing all stop words.

it *can* work if the query analyzer for your text field type is also 
configured to remove stopwords, and if you either: configure the 
StopFilter(s) to deal with token positions in the way the parser expects 
(i forget which one works, you have to play with it); OR us a "qs" (query 
slop) value that gives you enough slop to miss those empty stop word gaps.


-Hoss