That's what I thought you had meant before, but the Jira ticket indicates that you are looking for some extra level of AND/MUST outside of the OR, which is different from what you just indicated. In the ticket you say: "How can I achieve following? "+((fl:java fl:book))"", which has an extra AND outside of the inner sub-query, which is a little different than just "(fl:java fl:book)". Sure, the results should be the same, but why insist on the extra level of nested boolean query?
-- Jack Krupansky On Thu, Mar 17, 2016 at 12:50 AM, Modassar Ather <modather1...@gmail.com> wrote: > What I understand by q.op is the default operator. If there is no AND/OR > in-between the terms the default will be AND as per my setting of q.op=AND. > But what if the query has AND/OR explicitly put in-between the query terms? > I just think that if (A OR B) is the query then the result should be based > on any of the term's or both of the terms and not only both of the terms. > Please correct me if my understanding is wrong. > > Thanks, > Modassar > > On Wed, Mar 16, 2016 at 7:34 PM, Jack Krupansky <jack.krupan...@gmail.com> > wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
