Now you've confused me... Did you actually intend that q.op=AND was going to perform some function in a query with only two terms and and OR operator? I mean, why not just drop the q.op=AND?
-- Jack Krupansky On Wed, Mar 16, 2016 at 1:31 AM, Modassar Ather <modather1...@gmail.com> wrote: > Jack as suggested I have created following jira issue. > > https://issues.apache.org/jira/browse/SOLR-8853 > > Thanks, > Modassar > > > On Tue, Mar 15, 2016 at 8:15 PM, Jack Krupansky <jack.krupan...@gmail.com> > wrote: > > > That was precisely the point of the need for a new Jira - to answer > exactly > > the questions that you have posed - and that I had proposed as well. > Until > > some of the senior committers comment on that Jira you won't have > answers. > > They've painted themselves into a corner and now I am curious how they > will > > unpaint themselves out of that corner. > > > > -- Jack Krupansky > > > > On Tue, Mar 15, 2016 at 1:46 AM, Modassar Ather <modather1...@gmail.com> > > wrote: > > > > > Thanks Jack for your response. > > > The following jira bug for this issue is already present so I have not > > > created a new one. > > > https://issues.apache.org/jira/browse/SOLR-8812 > > > > > > Kindly help me understand that whether it is possible to achieve search > > on > > > ORed terms as it was done in earlier Solr version. > > > Is this behavior intentional or is it a bug? I need to migrate to > > > Solr-5.5.0 but not doing so due to this behavior. > > > > > > Thanks, > > > Modassar > > > > > > > > > On Fri, Mar 11, 2016 at 3:18 AM, Jack Krupansky < > > jack.krupan...@gmail.com> > > > wrote: > > > > > > > We probably need a Jira to investigate whether this really is an > > > explicitly > > > > intentional feature change, or whether it really is a bug. And if it > > > truly > > > > was intentional, how people can work around the change to get the > > > desired, > > > > pre-5.5 behavior. Personally, I always thought it was a mistake that > > q.op > > > > and mm were so tightly linked in Solr even though they are > independent > > in > > > > Lucene. > > > > > > > > In short, I think people want to be able to set the default behavior > > for > > > > individual terms (MUST vs. SHOULD) if explicit operators are not > used, > > > and > > > > that OR is an explicit operator. And that mm should control only how > > many > > > > SHOULD terms are required (Lucene MinShouldMatch.) > > > > > > > > > > > > -- Jack Krupansky > > > > > > > > On Thu, Mar 10, 2016 at 3:41 AM, Modassar Ather < > > modather1...@gmail.com> > > > > wrote: > > > > > > > > > Thanks Shawn for pointing to the jira issue. I was not sure that if > > it > > > is > > > > > an expected behavior or a bug or there could have been a way to get > > the > > > > > desired result. > > > > > > > > > > Best, > > > > > Modassar > > > > > > > > > > On Thu, Mar 10, 2016 at 11:32 AM, Shawn Heisey < > apa...@elyograg.org> > > > > > wrote: > > > > > > > > > > > On 3/9/2016 10:55 PM, Shawn Heisey wrote: > > > > > > > The ~2 syntax, when not attached to a phrase query (quotes) is > > the > > > > way > > > > > > > you express a fuzzy query. If it's attached to a query in > quotes, > > > > then > > > > > > > it is a proximity query. I'm not sure whether it means > something > > > > > > > different when it's attached to a query clause in parentheses, > > > > someone > > > > > > > with more knowledge will need to comment. > > > > > > <snip> > > > > > > > https://issues.apache.org/jira/browse/SOLR-8812 > > > > > > > > > > > > After I read SOLR-8812 more closely, it seems that the ~2 syntax > > with > > > > > > parentheses is the way that the effective mm value is expressed > > for a > > > > > > particular query clause in the parsed query. I've learned > > something > > > > new > > > > > > today. > > > > > > > > > > > > Thanks, > > > > > > Shawn > > > > > > > > > > > > > > > > > > > > > > > > > > >
