Re: Wild-card query behavior

Well it remind regular awkward parsing issues. Try to experiment with ={!join to=...from=... v='field:12*'} or ={!join to=... from=... v=$qq}=field:12* No more questions to ask. On Wed, Oct 9, 2019 at 4:39 PM Paresh wrote: > E.g. In query, join with wild-card query using parenthesis I get error

Re: Wild-card query behavior

E.g. In query, join with wild-card query using parenthesis I get error - "error-class","org.apache.solr.common.SolrException", "root-error-class","org.apache.solr.parser.ParseException"], "msg":"org.apache.solr.search.SyntaxError: Cannot parse 'solrField:(12*': Encountered \"\" at line

Re: Wild-card query behavior

Hello, Paresh. Please examine debugQuery output, otherwise 'doesn't work' is vague. On Wed, Oct 9, 2019 at 8:31 AM Paresh wrote: > Hi All, > > I am trying wild-card query with query, filter query with and without !join > and finding it difficult to understand the SOLR behavior. > > (-)

Wild-card query behavior

Hi All, I am trying wild-card query with query, filter query with and without !join and finding it difficult to understand the SOLR behavior. (-) wild-card like 12* in query: field:12* works well (-) wild-card like 12* in query with {!join to=... from=...}field:12* --> works well (-) wild-card

Re: Odd Boolean Query behavior in SOLR 3.6

Inner purely negative queries match nothing. A query is about matching, and skipping over things that don’t match. The fix is when using (-something) to do (*:* -something) to match everything and skip the negative clause items. In your example, try fq=((*:* -documentTypeId:3) AND

Odd Boolean Query behavior in SOLR 3.6

Hi Everyone, I have hit a weird behavior of Boolean Query, when I am running the query with below param’s it’s not behaving as expected. can you please help me understand the behavior here? q=*:*=((-documentTypeId:3)+AND+companyId:29096)=2.2=0=10=on=true èReturns 0 matches

Re: Wildcard query behavior.

Yes! wildcards are not analyzed. Thanks Shwan for reminding me. Thanks Erick for your response. Best, Modassar On Mon, Apr 18, 2016 at 8:53 PM, Erick Erickson wrote: > Here's a blog on the subject: > >

Re: Wildcard query behavior.

Here's a blog on the subject: https://lucidworks.com/blog/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/ bq: When validator is changed to validate, both at query time and index time, then should not validator*/validator return the same results at-least? This is one of

Re: Wildcard query behavior.

On 4/18/2016 1:18 AM, Modassar Ather wrote: > When I search for f:validator I get 80K+ documents whereas if I search for > f:validator* I get only around 150 results. > > When I checked on analysis page I see that validator is changed to > validate. Per my understanding in both the above cases it

Re: Wildcard query behavior.

Thanks Reth for your response. When validator is changed to validate, both at query time and index time, then should not validator*/validator return the same results at-least? E.g. 5 documents contains validator. At index time validator got changed to validate. Now when validator* is searched it

Re: Wildcard query behavior.

If you search for f:validat*, then I believe you will get same number of results. Please check. f:validator* is searching for records that have prefix "validator" where as field with stemmer which stems "validator" to "validate" (if this stemming was applied at index time as well as query time)

Wildcard query behavior.

Hi, Please help me understand following. I have analysis chain which uses KStemFilterFactory for a field. Solr version is 5.4.0 When I search for f:validator I get 80K+ documents whereas if I search for f:validator* I get only around 150 results. When I checked on analysis page I see that

Re: Query behavior.

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

Re: Query behavior.

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

Re: Query behavior.

I was just wanting to see the Jira clarified (without creating noise on the Jira), but if others feel they understand the relevance of the outer AND/+ to the stated problem, fine. I don't think I have anything else to add to the discussion at this stage. Now we sit and wait for some senior

Re: Query behavior.

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 wrote: > Jack

Re: Query behavior.

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

Re: Query behavior.

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

Re: Query behavior.

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

Re: Query behavior.

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 wrote: > That was precisely the point of the need for a new Jira - to answer exactly > the

Re: Query behavior.

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

Re: Query behavior.

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

Re: Query behavior.

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

Re: Query behavior.

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 wrote: > On 3/9/2016 10:55 PM, Shawn Heisey

Re: Query behavior.

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

Re: Query behavior.

On 3/9/2016 12:07 AM, Modassar Ather wrote: > Kindly help me understand the parsing of following query. I am using > edismax parser and Solr-5.5.0. > q.op is set to AND and there is no explicit mm value set. > > fl:(java OR book) => "boost(+((fl:java fl:book)~2),int(val))" > > When the query has

Re: Query behavior.

Hi, A suggestion will be very helpful. Thanks, Modassar On Wed, Mar 9, 2016 at 12:37 PM, Modassar Ather wrote: > Hi, > > Kindly help me understand the parsing of following query. I am using > edismax parser and Solr-5.5.0. > q.op is set to AND and there is no explicit

Query behavior.

Hi, Kindly help me understand the parsing of following query. I am using edismax parser and Solr-5.5.0. q.op is set to AND and there is no explicit mm value set. fl:(java OR book) => "boost(+((fl:java fl:book)~2),int(val))" When the query has explicit OR then why the ~2 is present in the parsed

Re: Query behavior difference.

Hi Modassar, It usually helps if you analyze extreme case: e.g. fl:a* What terms should be better match? Those who are shorter or all should be equally good? What should be top document? Assuming standard TF/IDF scoring is used, that would be one with the most terms that start with 'a'

Re: Query behavior difference.

Please help me understand why queries like wildcard, prefix and few others are re-written into constant score query? Why the scoring factors are not taken into consideration in such queries? Please correct me if I am wrong that this behavior is per the query type irrespective of the parser used.

Re: Query behavior difference.

The motivation for the constant-score rewrite is simply performance. As per the Javadoc: "*This method is faster than the BooleanQuery rewrite methods when the number of matched terms or matched documents is non-trivial. Also, it will never hit an errant BooleanQuery.TooManyClauses exception.*"

Re: Query behavior difference.

Thanks for your responses. Best, Modassar On Wed, Jan 6, 2016 at 9:27 PM, Jack Krupansky wrote: > The motivation for the constant-score rewrite is simply performance. As per > the Javadoc: > > "*This method is faster than the BooleanQuery rewrite methods when the >

Re: Query behavior difference.

Thanks for your response Ahmet. Best, Modassar On Mon, Jan 4, 2016 at 5:07 PM, Ahmet Arslan wrote: > Hi, > > I think wildcard queries fl:networ* are re-written into Constant Score > Query. > fl=*,score should returns same score for all documents that are retrieved. >

Query behavior difference.

Hi, Kindly help me understand how will relevance ranking differ int following searches. query : fl:network query : fl:networ* What I am observing that the results returned are different in both of them in a way that the top documents returned for q=fl:network is not present in the top results

Re: Query behavior difference.

Hi, I think wildcard queries fl:networ* are re-written into Constant Score Query. fl=*,score should returns same score for all documents that are retrieved. Ahmet On Monday, January 4, 2016 12:22 PM, Modassar Ather wrote: Hi, Kindly help me understand how will

Re: Difference in query behavior.

The mm parameter or default operator logic only applies to the top level of the query. Once you get nested in parentheses below the top level, Solr/Lucene reverts to the default of the OR (SHOULD) operator. -- Jack Krupansky On Mon, Nov 30, 2015 at 5:45 AM, Modassar Ather

Re: Difference in query behavior.

I cannot immediately explain the behaviour you are seeing, but can't you use a filter query to achieve the same? Add fq=topic:facet to your query string, and you'll be set. As to the original behaviour, the parsed query looks wrong, as it is missing a bracket. Can you provide all of the versions

Re: Difference in query behavior.

On 30 November 2015 at 05:45, Modassar Ather wrote: > > I have a query title:(solr lucene api). The mm is set to 100% using q.op as > +(title:solr **title:faceting** title:api)~3 Does it though? solr lucene api => solr faceting api! Is it possible you are staring at the

Re: Difference in query behavior.

gt; >>> Out of curiosity, how does the SpanQueryParser work on this? Or have >>> you stopped using that? >>> >>> Cheers, >>> >>> Tim >>> >>> -Original Message- >>> From: Modassar Ather [mailto:modather1..

Difference in query behavior.

Hi, I have a query title:(solr lucene api). The mm is set to 100% using q.op as AND. When the query is executed it returns documnets having all the terms. It parses to following: +(title:solr title:faceting title:api)~3 Similarlly I have another query like this topic:facet AND title:(solr lucene

changed query behavior

Hi, I have updated my solr instance from 4.5.1 to 4.7.1. Now my solr query failing some tests. Query: q=*:*fq=(title:((TE)))?debug=true Before the update: lstname=debug strname=rawquerystring*:*/str strname=querystring*:*/str strname=parsedqueryMatchAllDocsQuery(*:*)/str

Re: Join Query Behavior

leave off the join query in 4.5 and get the same results, which tells me obviously it is having no effect. Is there a change to the join query behavior between these releases, or could I have configured something differently in my 4.5.1 install? Thanks, Andy Pickler On Thu, Oct 24, 2013 at 2:42

Join Query Behavior

gives us different (and expected) results, while the query doesn't affect the results at all in 4.5. Is there any known join query behavior differences/fixes between 4.2 and 4.5 that might explain this, or should I be looking at other factors? Thanks, Andy Pickler

Re: Can anyone explain this Solr query behavior?

Hi Upayavira, Thank you for your analysis. I thought 'AND' groupings are supported as per documentation: http://docs.lucidworks.com/display/solr/The+Extended+DisMax+Query+Parser http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/queryparsersyntax.html#Grouping But yes,

Re: Can anyone explain this Solr query behavior?

should go away. -- Jack Krupansky -Original Message- From: Shankar Sundararaju Sent: Thursday, May 23, 2013 7:23 PM To: solr-user@lucene.apache.org Subject: Re: Can anyone explain this Solr query behavior? Hi Erick, Here's the output after turning on the debug flag: *q=text

Re: Can anyone explain this Solr query behavior?

remediation it was performing.. -- Jack Krupansky -Original Message- From: Shankar Sundararaju Sent: Friday, May 24, 2013 1:01 PM To: solr-user@lucene.apache.org Subject: Re: Can anyone explain this Solr query behavior? Hi Jack Krupansky, Thank you for your reply. I would like to know how

Re: Can anyone explain this Solr query behavior?

Please post the results of adding debug=query to the URL. That'll tell us what the query parser spits out which is much easier to analyze. Best Erick On Wed, May 22, 2013 at 12:16 PM, Shankar Sundararaju shan...@ebrary.com wrote: This query returns 0 documents: *q=(+Title:() +Classification:()

Re: Can anyone explain this Solr query behavior?

Hi Erick, Here's the output after turning on the debug flag: *q=text:()debug=query* yields response lst name=responseHeader int name=status0/int int name=QTime17/int lst name=params str name=indenttrue/str str name=qtext:()/str str name=debugquery/str /lst /lst result name=response

Re: Can anyone explain this Solr query behavior?

(+(doc-id:3000 DisjunctionMaxQuery((Publisher:and^2.0 | text:and | Classification:and^2.0 | Contributors:and^2.0 | Title:and^3.0/no_coord You're using edismax, not lucene. So AND is being considered as a search term, not an operator, and the word 'and' probably exists in 631580 documents.

Re: Can anyone explain this Solr query behavior?

: Can anyone explain this Solr query behavior? Hi Erick, Here's the output after turning on the debug flag: *q=text:()debug=query* yields response lst name=responseHeader int name=status0/int int name=QTime17/int lst name=params str name=indenttrue/str str name=qtext:()/str str name=debugquery

Can anyone explain this Solr query behavior?

This query returns 0 documents: *q=(+Title:() +Classification:() +Contributors:() +text:())* This returns 1 document: *q=doc-id:3000* And this returns 631580 documents when I was expecting 0: *q=doc-id:3000 AND (+Title:() +Classification:() +Contributors:() +text:())* Am I missing something

Strange query behavior

Hello, I have a title that says 3DVIA Studio amp; Virtools Maya and 3dsMax Exporters. The analysis tool for this field gives me these tokens:3dviadviastudio;virtoolmaya3dsmaxdssystèmmaxexport However, when i search for 3dsmax, i get no results :( Furthermore, if i search for dsmax i get the

Re: Strange query behavior

splitOnCaseChange is creating multiple tokens from 3dsMax disable it or enable catenateAll, use the analysys page in the admin tool to see exactly how your text will be indexed by analyzers without having to reindex your documents, once you have it right you can do a full reindex. On Mon, Jun 28,

Unexpected boolean query behavior

it does without the parentheses? Is there something I am missing in the way it processes boolean clauses? Thanks, Mark -- View this message in context: http://old.nabble.com/Unexpected-boolean-query-behavior-tp27166967p27166967.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Unexpected boolean query behavior

Message From: markwaddle m...@markwaddle.com To: solr-user@lucene.apache.org Sent: Thu, January 14, 2010 2:39:21 PM Subject: Unexpected boolean query behavior Here is my query: (virt* AND machine fingerprinting) OR (virt* AND encryption) OR (virt* AND anonymous) OR (virt* AND analytic

Re: Unexpected boolean query behavior

From: markwaddle m...@markwaddle.com To: solr-user@lucene.apache.org Sent: Thu, January 14, 2010 2:39:21 PM Subject: Unexpected boolean query behavior Here is my query: (virt* AND machine fingerprinting) OR (virt* AND encryption) OR (virt* AND anonymous) OR (virt* AND analytic

Re: Unexpected boolean query behavior

: Re: Unexpected boolean query behavior That is a reasonable question. The problem here is that my users have already created numerous queries just like this one, using ANDs and ORs. My users are very technical and they have been using the results of these queries for months now to perform

Re: Unexpected boolean query behavior

in context: http://old.nabble.com/Unexpected-boolean-query-behavior-tp27166967p27170172.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Unexpected boolean query behavior

://wiki.apache.org/lucene-java/BooleanQuerySyntax Otis -- Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch -- View this message in context: http://old.nabble.com/Unexpected-boolean-query-behavior-tp27166967p27170172.html Sent from the Solr - User mailing list archive at Nabble.com