An, SOW may be a red-herring then.
The fact that file_type is defined as Keyword is the key.
KeywordTokenizerFactory is expressly about _not_ breaking up the input
in any way.
You're right, you could reformulate your query. I think, though, that
you'd be better off changing the tokenizer to somet
Thanks Erick for pushing me into the right direction.
so sow=false, but i think that it is the default behavior so I didn't
expect this to cause any strange outcome. However the reason Folder_id is
being treated differently than the others is the schema definition.
Folder_id is a long. While file
OK, that's definitely weird. A separate fq clause like
fq={!q.op=OR}file_type:(jpg jpeg)
should _not_ parse in to:
file_type:jpg jpeg
Hmmm, any possibility that Split On Whitespace is somehow being set
(SOW) to false? Why in the world it would only show up like this is a
mystery, just askin'.
It
Thanks Erik. Yes some similar queries are also working for me.
"file_type:(jpg%20OR%20jpeg)" and "{!q.op=OR}file_type:(jpg OR jpeg)" are
translated into the following which is correct.
- "file_type:jpg file_type:jpeg"
While "{!q.op=OR}file_type:(jpg jpeg)" is translated into file_type:jpg
jp
1> similar queries work for me just fine with the techproducts exapmle
2> that's not what I wanted, you just reiterated the _input_.
I asked for the results when adding &debug=query to the string so you
can see the parsed query.
You should see something similar to:
"parsed_filter_queries":["file_t
1. input: fq={!q.op=OR}file_type:(jpg%20jpeg) (fails, no results)
- fq: [
- "id:file_258470818866",
- "{!q.op=OR}file_type:(jpg jpeg)"
],
2. input: fq={!q.op=OR}file_type:(jpg%20OR%20jpeg) (This works)
- fq: [
- "id:file_258470818866",
- "{!q.op=OR}file_t
What does adding &debug=query show in the two cases?
Best,
Erick
On Wed, Dec 27, 2017 at 3:40 PM, Nawab Zada Asad Iqbal wrote:
> Hi,
>
> Are the following two queries equal:
>
> In my understanding, I can specify the arguments the operator once in the
> {} local parameter syntax (example 1) or I
