The analyzer/query generator for a tokenized field will in fact tokenize the
value in quotes, but it will generate a "phrase query" to assure that the
list of terms occur as a phrase in the index.
-- Jack Krupansky
-----Original Message-----
From: Burgmans, Tom
Sent: Thursday, February 28, 2013 11:33 AM
To: solr-user@lucene.apache.org
Subject: RE: Search in String and Text_en fields simultaneously with edismax
Ah OK. I didn't have a good view of query parsing vs query generation.
Thanks for clearing this up.
So it means that searching in a tokenized and non-tokenized field
simultaneously is not possible when I want
- the expression parsed as phrase for the non-tokenized field
- the expression parsed as multiple tokens for the tokenized field
?
If possible, I'd like to avoid writing my own query parser.
-----Original Message-----
From: Jack Krupansky [mailto:j...@basetechnology.com]
Sent: Thursday 28 February 2013 05:05
To: solr-user@lucene.apache.org
Subject: Re: Search in String and Text_en fields simultaneously with edismax
Query text is always "tokenized" (more properly, "parsed"), unless the text
is enclosed in quotes or spaces are escaped with backslash. Try:
q=valueadd:"test . test2"
or
q=valueadd:test\ .\ test2
Parentheses simply provide grouping, either to control boolean operator
evaluation order or to apply a field name to a sequence of query tokens (as
you have written.)
The analyzer or field type is only consulted when the query is generated,
not while it is being parsed. The same identical parsing rules apply to both
tokenized and non-tokenized fields. What a field type's analyzer does with
its value is irrelevant to query parsing.
-- Jack Krupansky
-----Original Message-----
From: Burgmans, Tom
Sent: Thursday, February 28, 2013 10:48 AM
To: solr-user@lucene.apache.org
Subject: Search in String and Text_en fields simultaneously with edismax
I have a field "valueadd" of type String and field "body" of type text_en
(with tokenization and linguistic processing).
When I search with edismax against field valueadd like this:
q=valueadd:(test . test2)
I see that the parsed query is
(valueadd:test valueadd:. valueadd:test2)~3
Why not (valueadd:test . test2) ? It looks like the query is tokenized while
field type String doesn't have a tokenizer configured.
I know I could construct my query as:
q=valueadd:"test . test2"
in which case the phrase is searched as a whole against valueadd. But why
doesn't that happen without quotes?
The reason I ask:
For a simultaneous search in multiple fields I like to include field
valueadd in the qf parameter which contains String and text_en fields, like:
&qf=valueadd body
How can I search both fields simultaneously without duplicating search
terms, while the query is (whitespace) tokenized for "body" but search as a
phrase for "valueadd"?
Thanks,
Tom Burgmans
This email and any attachments may contain confidential or privileged
information
and is intended for the addressee only. If you are not the intended
recipient, please
immediately notify us by email or telephone and delete the original email
and attachments
without using, disseminating or reproducing its contents to anyone other
than the intended
recipient. Wolters Kluwer shall not be liable for the incorrect or
incomplete transmission of
of this email or any attachments, nor for unauthorized use by its employees.
Wolters Kluwer nv has its registered address in Alphen aan den Rijn, The
Netherlands, and is registered
with the Trade Registry of the Dutch Chamber of Commerce under number
33202517.
This email and any attachments may contain confidential or privileged
information
and is intended for the addressee only. If you are not the intended
recipient, please
immediately notify us by email or telephone and delete the original email
and attachments
without using, disseminating or reproducing its contents to anyone other
than the intended
recipient. Wolters Kluwer shall not be liable for the incorrect or
incomplete transmission of
of this email or any attachments, nor for unauthorized use by its employees.
Wolters Kluwer nv has its registered address in Alphen aan den Rijn, The
Netherlands, and is registered
with the Trade Registry of the Dutch Chamber of Commerce under number
33202517.
