That implies that you’re using two different queryParsers, one for the “q”
portion and one for the “fq” portion. My guess is that you have solrconfig
/select or /query configured to use (e)dismax but your fq clause is being
parsed by, the LuceneQueryParser.
You can specify the parser via local
Thanks Erick for the clarification. How does the ps work for fq? I
configured ps=4 for q, it doesn't apply to fq though. For phrase queries in
fq seems ps=0 is used. Is there a way to config it for fq also?
Best,
Wei
On Tue, Jun 25, 2019 at 9:51 AM Erick Erickson
wrote:
> q and fq do _exactly
q and fq do _exactly_ the same thing in terms of query parsing, subject to all
the same conditions.
There are two things that apply to fq clauses that have nothing to do with the
query _parsing_.
1> there is no scoring, so it’s cheaper from that perspective
2> the results are cached in a bitmap
Thanks Shawn! I didn't notice the asterisks are created during copy/paste,
one lesson learned :)
Does that mean when fq is applied to text fields, it is doing text match
in the field just like q in a query field? While for string fields, it is
exact match.
If it is a phrase query, what are the v
On 6/24/2019 5:37 PM, Wei wrote:
I'm assuming that the asterisks here are for emphasis, that they are not
actually present. This can be very confusing. It is far better to
relay the precise information and not try to emphasize anything.
For query q=*:*&fq=description:”ice cream”, the f
First one treats space as end of operation, so the second keyword is
searched against default field (id). Try putting the whole thing into the
quotes. Or use Field Query Parser:
https://lucene.apache.org/solr/guide/7_5/other-parsers.html#field-query-parser
Regards,
Alex.
On Wed, Oct 24, 2018,
bq. is there any difference if the fq field is a string field vs test
Absolutely. string fields are not analyzed in any way. They're not
tokenized. There are case sensitive. Etc. For example takd
My dog
as input. A string field will have a _single_ token "My dog.". It will
not match a search on "
btw, is there any difference if the fq field is a string field vs test
field?
On Wed, Jul 11, 2018 at 11:59 AM, Wei wrote:
> Thanks Erick and Andrea! If my default operator is OR, fq=
> my_text_field:(Jurassic park the movie) is equivalent to
> my_text_field:(Jurassic
> OR park OR the OR mov
Thanks Erick and Andrea! If my default operator is OR, fq=
my_text_field:(Jurassic park the movie) is equivalent to
my_text_field:(Jurassic
OR park OR the OR movie)? That make sense.
On Wed, Jul 11, 2018 at 9:06 AM, Andrea Gazzarini
wrote:
> The syntax is valid in all those three examples, th
The syntax is valid in all those three examples, the right one depends on
what you need.
The first query executes a proximity search (you can think to a phrase
search, for simplicity) so it returns no result because probably you don't
have any matching docs with that whole literal.
The second is
1> is looking for the _phrase_, so the four tokens "jurassic" "park"
"the" "movie" have to appear next to each other in that order.
2> is looking for the four tokens anywhere in the field. Whether they
_all_ must appear depends on whether the default operator (OR or AND).
3> is parsed as my_text_
As with many features in Solr, there is no hard limit per se, but the "rule"
is to use the feature in moderation.
If you find yourself using a "big" filter query, it likely means that you
have chosen a poor design or are misusing Solr in some way. The response
should be to correct your design,
I am unsure what you mean when you say /how big a filter query can be ? /. Do
you mean how long can a single filter query can be or a limit on number of
filter queries that can be put?
For the former you may want to visit the maxBooleanClauses in your
solrconfig. Try the link:
he tottp://wiki.apac
13 matches
Mail list logo
