Well it remind regular awkward parsing issues. Try to experiment with
&fq={!join to=...from=... v='field:12*'} or &fq={!join to=... from=...
v=$qq}&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 g
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 1
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
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 li
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 companyId:29
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=*:*&fq=((-documentTypeId:3)+AND+companyId:29096)&version=2.2&start=0&rows=10&indent=on
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:
>
> https://lucidworks.com/blog/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-s
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 those
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 s
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
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) it
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 valid
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
ou
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 Krupan
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
committe
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 as suggested I have crea
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:
> What I understand by
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 le
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
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 questions that you have posed - an
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 wi
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
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
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 wrote:
> > The ~2 syntax, w
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 cl
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 ex
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 mm value set.
>
> fl:(jav
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
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
> number of matched terms or ma
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.*"
S
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' especiall
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.
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.
>
> Ahmet
>
>
>
> On Monday,
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 relevance ranking differ int f
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 of
gt; you stopped using that?
>>>
>>> Cheers,
>>>
>>> Tim
>>>
>>> -Original Message-
>>> From: Modassar Ather [mailto:modather1...@gmail.com]
>>> Sent: Monday, November 30, 2015 5:46 AM
>>> To: solr-user@luce
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
wrote:
> Hi,
>
> I hav
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 wrong tab and the counts
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
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
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:((T&E)))?debug=true
Before the update:
*:*
*:*
MatchAllDocsQuery(*:*)
*:*
LuceneQParser
(title:((T&E)))
+title:t&e +title:t +title:e
...
After the update:
*:*
*:*
Mat
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 PM, Andy Pickler wrote:
> We're attempting
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
what 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
s why you see "and" included in the parsed query as if it
> were a term. And I believe it turns "text:()" into "text:"()"", which makes
> the original Lucene error go away, but the "()" analyzes to nothing and
> generates no term
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, q=doc-id:30
s why you see "and" included in the parsed query as if it
were a term. And I believe it turns "text:()" into "text:"()"", which makes
the original Lucene error go away, but the "()" analyzes to nothing and
generates no term in the query.
So,
(+(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.
Why
Hi Erick,
Here's the output after turning on the debug flag:
*q=text:()&debug=query*
yields
0
17
true
text:()
query
text:()
text:()
(+())/no_coord
+()
ExtendedDismaxQParser
*q=doc-id:3000&debug=query*
yields
0
17
doc-id:3000
query
:
:
doc-id:3000
doc-id:300
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
wrote:
> This query returns 0 documents: *q=(+Title:() +Classification:()
> +Contributors:(
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 here
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,
Hello,
I have a title that says "3DVIA Studio & 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 t
It's a FAQ, so I knew exactly where to look.
Otis
--
Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch
- Original Message
> From: markwaddle
> To: solr-user@lucene.apache.org
> Sent: Thu, January 14, 2010 6:45:17 PM
> Subject: Re: Unexpected boole
>>
>> Does this help?
>> http://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-quer
ne - 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.
: 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
>
t; --
> Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch
>
>
>
> - Original Message
>> From: markwaddle
>> To: solr-user@lucene.apache.org
>> Sent: Thu, January 14, 2010 2:39:21 PM
>> Subject: Unexpected boolean query behavior
>>
>>
>> Here i
- Lucene - Nutch
- Original Message
> From: markwaddle
> 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* AN
es the way 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.
60 matches
Mail list logo
