Ah, I just looked at my code and I just replace single quotes with a space
since it’s the same thing. Thanks for the clarification my bad for bad info. I
still prefer a post over a get however
> On Sep 11, 2021, at 12:55 PM, Erik Hatcher <erik.hatc...@gmail.com> wrote:
>
> That's not true in this case Dave. The single quotes are needed to
> encapsulate an inner parameter value that has spaces. It's not a get vs
> post thing for this.
>
> Erik
>
>> On Fri, Sep 10, 2021, 11:45 Dave <hastings.recurs...@gmail.com> wrote:
>>
>> With a post you don’t have to worry about single/double quotes or any
>> other characters like an @ or & in your query, they all go in as is from
>> the user input, maybe not using curl but every language has a post
>> operation to utilize. Kind of like placeholders for a sql query, they can
>> contain anything and you don’t have to clean the user input (php bad Perl
>> good)
>>
>>> On Sep 10, 2021, at 11:35 AM, Andy Coulson <andy.coul...@epicor.com>
>> wrote:
>>>
>>> I'm not sure what you mean? If you mean why use a get vs a post, I
>> guess just because we started with copying the url generated by the UI
>> query console and just kept tweaking that. I supposed we could also just
>> use postman to experiment using posts if that is supported.
>>>
>>> -----Original Message-----
>>> From: David Hastings <hastings.recurs...@gmail.com>
>>> Sent: Friday, September 10, 2021 9:34 AM
>>> To: users@solr.apache.org
>>> Subject: Re: qf with multiple fields in _query_ with edismax
>>>
>>> Do you mind if I ask why not use a post to solr?
>>>
>>>> On Fri, Sep 10, 2021 at 10:18 AM Andy Coulson <andy.coul...@epicor.com>
>>>> wrote:
>>>>
>>>> Thanks Erik,
>>>>
>>>> That did the trick! My real use case will have additional predicates -
>>>> I merely trimmed it down to reproduce and illustrate the problem. I
>>>> real query will probably be something like (without encoding):
>>>>
>>>> q= locale:en AND thingType:part AND _query_:"{!edismax qf='object_name
>>>> thing_name' pf=thing_name^10 v=$qq mm=$minMatch}"&qq=clutch
>>>> cable&minMatch=100%&fl=*,score
>>>>
>>>> -----Original Message-----
>>>> From: Erik Hatcher <erik.hatc...@gmail.com>
>>>> Sent: Friday, September 10, 2021 8:40 AM
>>>> To: users@solr.apache.org
>>>> Subject: Re: qf with multiple fields in _query_ with edismax
>>>>
>>>> Andy,
>>>>
>>>> Use single quotes around the inner parameters, such as {!edismax
>>>> qf='object_name thing_name'}. Going even further, use the `v`
>>>> parameter to encapsulate the query string inside as well, as the parser
>> eats everything
>>>> after the closing curly bracket otherwise. {!edismax qf='object_name
>>>> thing_name' v='r'}. Beyond that, if the query string is potentially
>>>> complex, and may itself contain a single quote, use param
>> indirection....
>>>>
>>>> q={!edismax qf='object_name thing_name' v=$qq mm='100%'}&qq=r
>>>>
>>>> If you're only doing a single edismax, then using the _query_ here is
>>>> not necessary though.
>>>>
>>>> Erik
>>>>
>>>>
>>>>
>>>>> On Sep 9, 2021, at 5:23 PM, Andy Coulson <andy.coul...@epicor.com>
>>>> wrote:
>>>>>
>>>>> There is precious little documentation on the _query_ magic field,
>>>>> but
>>>> from what I understand, it should take whatever parameters are
>>>> supported by parser.
>>>>> I am trying to provide multiple filed names to the qf parameter, but
>>>> nothing I try works. Examples I have found googling indicate my syntax
>>>> should be ok.
>>>>>
>>>>> I am using the edismax parser and version 6.6
>>>>>
>>>>> I try this, where the term "r" does exists in thing_name (but not in
>>>> object_name), but get no results:
>>>>> http://localhost:8983/solr/myCore/select?q=_query_ <
>>>> http://localhost:8983/solr/myCore/select?q=_query_
>>>>> :"{!edismax%20qf=object_name%20thing_name}r"&fl=*%2Cscore
>>>>>
>>>>> example also suggest that having the fl parameter inside the braces
>>>> should work, but it is ignored, as are other edismax params like mm.
>>>>>
>>>>> Andy Coulson
>>>>> Principal Software Engineer
>>>>> Epicor Software Corporation
>>>>> www.epicor.com <http://www.epicor.com/>
>>>>> Tel.: (512) 328-2300
>>>>> Cell: (512) 517-2494
>>>>> E-Mail: andy.coul...@epicor.com <mailto:andy.coul...@epicor.com>
>>>>
>>>>
>>
