lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Benedetti <abenede...@apache.org>
Subject Re: Query behavior.
Date Fri, 18 Mar 2016 10:06:18 GMT
I think what he tried to explain was :
" Input query : *fl:(java OR book)*
 Instead of having the query parser parsing :
 *+((fl:java fl:book)~2) *( which seems what is happening right now)
He want the query parser to parse :

+((fl:java fl:book)) ( without the mm expressed)

More than the outer level of AND , I think the concern is in the absence of
the ~2 operator ( mm=2 set automatically) .

Anyway I can't reproduce the issue :(

P.S. taking a brief look into the code
: org/apache/solr/search/ExtendedDismaxQParser.java:341
I suggest you to debug from that point as the comment says :

// For correct lucene queries, turn off mm processing if there
// were explicit operators (except for AND).
if (query instanceof BooleanQuery) {
query = SolrPluginUtils.setMinShouldMatch((BooleanQuery)query,
config.minShouldMatch, config.mmAutoRelax);
}

I have no time now,
Cheers

On Fri, Mar 18, 2016 at 4:39 AM, Jack Krupansky <jack.krupansky@gmail.com>
wrote:

> You still haven't explained what exactly you are trying to accomplish with
> that outer level AND/+/MUST. Please be specific - why you insist on
> "+((fl:java
> fl:book))" rather than  "fl:java fl:book".
>
> -- Jack Krupansky
>
> On Fri, Mar 18, 2016 at 12:12 AM, Modassar Ather <modather1981@gmail.com>
> wrote:
>
> > What I understand by "+((fl:java fl:book))" is any of the terms should be
> > present in the complete query. Please correct me if I am wrong.
> > What I want to achieve is (A OR B) where any of the term or both of the
> > term will cause a match.
> >
> > Thanks,
> > Modassar
> >
> > On Thu, Mar 17, 2016 at 10:32 AM, Jack Krupansky <
> jack.krupansky@gmail.com
> > >
> > wrote:
> >
> > > 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 <
> modather1981@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.krupansky@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 <
> > > modather1981@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.krupansky@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 <
> > > > > modather1981@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.krupansky@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
<
> > > > > > > modather1981@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 <
> > > > > > apache@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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
--------------------------

Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti

"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"

William Blake - Songs of Experience -1794 England

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message