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>
> >>
> >>
>
