Re: strange behavior of solr query parser

olr/commit/bf9db95f218f49bac8e7971eb953a9fd9d13a2f0#diff-269ae02e56283ced3ce781cce21b3147R563 sincerely hongtai 送信元: "Staley, Phil R - DCF" Reply-To: "d...@lucene.apache.org" 日付: 2020年3月2日 月曜日 22:38 宛先: solr_user lucene_apache , "d...@lucene.apache.org" 件名: Re: strange behavior of solr query p

Re: strange behavior of solr query parser

I believe we are experiencing the same thing. We recently upgraded to our Drupal 8 sites to SOLR 8.3.1. We are now getting reports of certain patterns of search terms resulting in an error that reads, “The website encountered an unexpected error. Please try again later.” Below is a list of

Re: strange behavior

Hi David, I see. It fixed now by adding the (). Thank you so much! q=audit_author.name:(Burley,%20S.K.)%20AND%20entity.type:polymer -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: strange behavior

Hi Shawn, I see. I added () and it works now. Thank you very much for your help! q=audit_author.name:(Burley,%20S.K.)%20AND%20entity.type:polymer&rows=1 -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: strange behavior

On 6/6/2019 12:46 PM, Wendy2 wrote: Why "AND" didn't work anymore? I use Solr 7.3.1 and edismax parser. Could someone explain to me why the following query doesn't work any more? What could be the cause? Thanks! q=audit_author.name:Burley,%20S.K.%20AND%20entity.type:polymer It worked previousl

Re: strange behavior

audit_author.name:Burley,%20S.K. translates to audit_author.name:Burley, DEFAULT_OPERATOR DEFAULT_FIELD:S.K. On Thu, Jun 6, 2019 at 2:46 PM Wendy2 wrote: > > Hi, > > Why "AND" didn't work anymore? > > I use Solr 7.3.1 and edismax parser. > Could someone explain to me why the following query

Re: Strange Behavior When Extracting Features

If anyone else is following this thread, I replied on the Jira. On Mon, Oct 16, 2017 at 4:07 AM, alessandro.benedetti wrote: > This is interesting, the EFI parameter resolution should work using the > quotes independently of the query parser. > At that point, the query parsers (both) receive a m

Re: Strange Behavior When Extracting Features

This is interesting, the EFI parameter resolution should work using the quotes independently of the query parser. At that point, the query parsers (both) receive a multi term text. Both of them should work the same. At the time I saw the mail I tried to reproduce it through the LTR module tests and

Re: Strange Behavior When Extracting Features

I believe I've discovered a workaround. If you use: { "store": "redhat_efi_feature_store", "name": "case_description_issue_tfidf", "class": "org.apache.solr.ltr.feature.SolrFeature", "params": { "q":"{!dismax qf=text_tfidf}${text}" } } i

Re: Strange Behavior When Extracting Features

I think this has nothing to do with the LTR plugin. The problem here should be just the way you use the local params, to properly pass multi term local params in Solr you need to use *'* : efi.case_description='added couple of fiber channel' This should work. If not only the first term will be pa

Re: Strange behavior of solr

See example/films/README.txt The “name” field is guessed incorrectly (because the first film has name=“.45”, so indexing errors once it hits a name value that is no longer numeric. The README provides a command to define the name field *before* indexing. If you’ve indexed and had the name fie

Re: Strange behavior of solr

Is there any error message in the log when Solr stops indexing the file at line 2046? Regards, Edwin On 2 September 2015 at 17:17, Long Yan wrote: > Hey, > I have created a core with > bin\solr create -c mycore > > I want to index the csv sample files from solr-5.2.1 > > If I index film.csv und

Re: Strange Behavior

On 8/23/2014 9:01 AM, Jack Krupansky wrote: > It sounds as if you are trying to treat hyphen as a digit so that > negative numbers are discrete terms. But... that conflicts with the use > of hyphen as a word separator. Sorry, but WDF does not support both. > Pick one or the other, you can't have bo

Re: Strange Behavior

It sounds as if you are trying to treat hyphen as a digit so that negative numbers are discrete terms. But... that conflicts with the use of hyphen as a word separator. Sorry, but WDF does not support both. Pick one or the other, you can't have both. But first, please explain your intended use

Re: Strange Behavior with Solr in Tomcat.

> > > log level in Solr to get more information logged > > > > > > > -Original Message- > > > > From: S.L [mailto:simpleliving...@gmail.com] > > > > Sent: June-06-14 2:33 PM > > > > To: solr-user@lucene.apache.org > >

Re: Strange Behavior with Solr in Tomcat.

race the process if you`re running on Unix or changed > the > > log level in Solr to get more information logged > > > > > -Original Message- > > > From: S.L [mailto:simpleliving...@gmail.com] > > > Sent: June-06-14 2:33 PM > >

Re: Strange Behavior with Solr in Tomcat.

June-06-14 2:33 PM > > To: solr-user@lucene.apache.org > > Subject: Re: Strange Behavior with Solr in Tomcat. > > > > Anyone folks? > > > > > > On Wed, Jun 4, 2014 at 10:25 AM, S.L wrote: > > > > > Hi Folks, > > > > > &g

RE: Strange Behavior with Solr in Tomcat.

6-14 2:33 PM > To: solr-user@lucene.apache.org > Subject: Re: Strange Behavior with Solr in Tomcat. > > Anyone folks? > > > On Wed, Jun 4, 2014 at 10:25 AM, S.L wrote: > > > Hi Folks, > > > > I recently started using the spellchecker in my solrcon

Re: Strange Behavior with Solr in Tomcat.

Anyone folks? On Wed, Jun 4, 2014 at 10:25 AM, S.L wrote: > Hi Folks, > > I recently started using the spellchecker in my solrconfig.xml. I am able > to build up an index in Solr. > > But,if I ever shutdown tomcat I am not able to restart it.The server never > spits out the server startup time

Re: Strange Behavior with Solr in Tomcat.

Hi, This is not a case of accidental deletion , the only way I can restart the tomcat is by deleting the data directory for the index that was created earlier, this started happening after I started using spellcheckers in my solrconfig.xml. As long as the Tomcat is running its fine. Any help from

Re: Strange Behavior with Solr in Tomcat.

I guess if you try to copy the index and then kill the process of tomcat then it might help. If still the index need to be delete you would have the back up. Next time always make back up. On Jun 4, 2014 7:55 PM, "S.L" wrote: > Hi Folks, > > I recently started using the spellchecker in my solrcon

Re: Strange behavior of edismax and mm=0 with long queries (bug?)

Actually I found why... I had and as lowercase word in my queries at the checkbox does not seem to work in the admin UI. adding lowercaseOperators=false made the queries work. 2014-04-04 18:10 GMT+02:00 Nils Kaiser : > Hey, > > I am currently using solr to recognize songs and people from a list

Re: Strange behavior of edismax and mm=0 with long queries (bug?)

Set the q.op parameter to OR and set mm=10% or something like that. The idea is to not excessively restrict the documents that will match, but weight the matched results based on how many word pairs and triples do match. In addition, use the pf parameter to provide extra weight when the full que

Re: Strange behavior while deleting

aster than the other. -- Jack Krupansky -Original Message- From: abhishek.netj...@gmail.com Sent: Monday, March 31, 2014 5:48 AM To: solr-user@lucene.apache.org ; solr-user@lucene.apache.org Subject: Re: Strange behavior while deleting Hi, These settings are commented in schema. These ar

Re: Strange behavior while deleting

: solr-user@lucene.apache.org Reply To: solr-user@lucene.apache.org Subject: Re: Strange behavior while deleting Do the two cores have identical schema and solrconfig files? Are the delete and merge config settings the sameidentical? Are these two cores running on the same Solr server, or two

Re: Strange behavior while deleting

Do the two cores have identical schema and solrconfig files? Are the delete and merge config settings the sameidentical? Are these two cores running on the same Solr server, or two separate Solr servers? If the latter, are they both running the same release of Solr? How big is the discrepancy

Re: Strange behavior on text field with number-text content

Hmmm, there are two things you _must_ get familiar with when diagnosing these .. 1> admin/analysis. That'll show you exactly what the analysis chain does, and it's not always obvious. 2> add &debug=query to your input and look at the parsed query results. For instance, this "name:4nSolut

Re: Strange behavior on text field with number-text content

solr-user-unsubscribe 2013/5/28 Michał Matulka > Thanks for your responses, I must admit that after hours of trying I > made some mistakes. > So the most problematic phrase will now be: > "4nSolution Inc." which cannot be found using query: > > name:4nSolution > > or even > > name:4nSolution

Re: Strange behavior on text field with number-text content

Thanks for your responses, I must admit that after hours of trying I made some mistakes. So the most problematic phrase will now be: "4nSolution Inc." which cannot be found using query: name:4nSolution or even name:4nSolution Inc.

Re: Strange behavior on text field with number-text content

Hmmm, with 4.x I get much different behavior than you're describing, what version of Solr are you using? Besides Alex's comments, try adding &debug=query to the url and see what comes out from the query parser. A quick glance at the code shows that DefaultAnalyzer is used, which doesn't do any an

Re: Strange behavior on text field with number-text content

What does analyzer screen say in the Web AdminUI when you try to do that? Also, what are the tokens stored in the field (also in Web AdminUI). I think it is very strange to have TextField without a tokenizer chain. Maybe you get a standard one assigned by default, but I don't know what the standa

Re: Strange behavior with search on empty string and NOT

: Would it be a good idea to have Solr throw syntax error if an empty string : query occurs? erick's explanation wasn't very precise ... solr doesn't have any special handling of "empty strings", but what you are searching for *might* be a totally valid query based on how the field type is c

Re: Strange behavior with search on empty string and NOT

Would it be a good idea to have Solr throw syntax error if an empty string query occurs? -- View this message in context: http://lucene.472066.n3.nabble.com/Strange-behavior-with-search-on-empty-string-and-NOT-tp3818023p3823572.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Strange behavior with search on empty string and NOT

Because Lucene query syntax is not a strict Boolean logic system. There's a good explanation here: http://www.lucidimagination.com/blog/2011/12/28/why-not-and-or-and-not/ Adding &debugQuery=on to your search is your friend .. You'll see that your return (at least on 3.5 with going at /solr/select)

Re: strange behavior of scores and term proximity use

You might try with a less "fraught" search phrase, "to be or not to be" is a classic query that may be all stop words. Otherwise, I'm clueless. On Wed, Nov 23, 2011 at 3:15 PM, Ariel Zerbib wrote: > I tested with the version 4.0-2011-11-04_09-29-42. > > Ariel > > > 2011/11/17 Erick Erickson >

Re: strange behavior of scores and term proximity use

I tested with the version 4.0-2011-11-04_09-29-42. Ariel 2011/11/17 Erick Erickson > Hmmm, I'm not seeing similar behavior on a trunk from today, when did > you get your copy? > > Erick > > On Wed, Nov 16, 2011 at 2:06 PM, Ariel Zerbib > wrote: > > Hi, > > > > For this term proximity query: a

Re: strange behavior of scores and term proximity use

Hmmm, I'm not seeing similar behavior on a trunk from today, when did you get your copy? Erick On Wed, Nov 16, 2011 at 2:06 PM, Ariel Zerbib wrote: > Hi, > > For this term proximity query: ab_main_title_l0:"to be or not to be"~1000 > > http://localhost:/solr/select?q=ab_main_title_l0%3A%22og

Re: Strange behavior

Of course, i did stop the solr before copying the index. Deleting index and reindexing on production server did solve an issue. Strange, but working.. > Have you stopped Solr before manually copying the data? This way you > can be sure that index is the same and you didn't have any new docs

Re: Strange behavior

Have you stopped Solr before manually copying the data? This way you can be sure that index is the same and you didn't have any new docs on the fly. 2011/6/14 Denis Kuzmenok : > What  should  i provide, OS is the same, environment is the same, solr > is  completely  copied,  searches  work,  excep

Re: Strange behavior

Well, you could provide the results with &debugQuery=on. You could provide the schema.xml and solrconfig.xml files for both. You could provide a listing of your index files. You could provide some evidence that you've tried chasing down your problem using tools like Luke or the Solr admin interface

Re: Strange behavior

What should i provide, OS is the same, environment is the same, solr is completely copied, searches work, except that one, and that is strange.. > I think you will need to provide more information than this, no-one on this > list is omniscient AFAIK. > François > On Jun 14, 2011, at 10:

Re: Strange behavior

I think you will need to provide more information than this, no-one on this list is omniscient AFAIK. François On Jun 14, 2011, at 10:44 AM, Denis Kuzmenok wrote: > Hi. > > I've debugged search on test machine, after copying to production server > the entire directory (entire solr director

Re: strange behavior of echoParams

Hi Erik, never mind. Can't reproduce this strange behavior. Obviously stopping and starting of solr solved this. Thanks, Bernd Am 13.04.2011 16:00, schrieb Erik Hatcher: What does the parsed query look like with debugQuery=true for both scenarios? Any difference? Doesn't make any sense that e

Re: strange behavior of echoParams

What does the parsed query look like with debugQuery=true for both scenarios? Any difference? Doesn't make any sense that echoParams would have an effect, unless somehow your search client is relying on parameters returned to do something with them.?! Erik On Apr 13, 2011, at 09:57 ,

RE: Strange behavior for certain words

Hi,        Thanks for your response. Attached are the Schema.xml and sample docs that were indexed. The query and response are as below. The attachment Prodsku4270257.xml has a field "paymenttype" whose value is 'prepaid'. query: q=prepaid&start=0&rows=10&fl=*%2Cscore&qt=standard&wt=json&debugQu

RE: Strange behavior for certain words

Hi Rama, What field types are these Title and Description? You may go to SOLR admin console and try "Analysis", and select the field type that you have used for Title and Description and provide those words Prepaid and Postpaid in the indexing analyzer and see how is it storing the information.

RE: Strange behavior for certain words

"time":0.0}, "org.apache.solr.handler.component.MoreLikeThisComponent":{ "time":0.0}, "org.apache.solr.handler.component.HighlightComponent":{ "time":0.0}, "org.apache.solr.handler.component.DebugComponent":{ "tim

Re: Strange behavior for certain words

Hmmm, there's not much information to go on here. You might review this page: http://wiki.apache.org/solr/UsingMailingLists and post with more information. At minimum, the field definitions, the query output (include &debugQuery=on), perhaps what comes out of the analysis admin page for both indexi

Re: Strange Behavior When Using CSVRequestHandler

It puzzles me too. I don't know the internals of that code well enough to speculate, but once you're into undefined behavior, I have great faith in *many* inexplicable things happening. Erick On Thu, Jan 7, 2010 at 9:45 AM, danben wrote: > > Erick - thanks very much, all of this makes sense

Re: Strange Behavior When Using CSVRequestHandler

Erick - thanks very much, all of this makes sense. But the one thing I still find puzzling is the fact that re-adding the file a second, third, fourth etc time causes numDocs to increase, and ALWAYS by the same amount (141,645). Any ideas as to what could cause that? Dan Erick Erickson wrote:

Re: Strange Behavior When Using CSVRequestHandler

I think the root of your problem is that unique fields should NOT be multivalued. See http://wiki.apache.org/solr/FieldOptionsByUseCase?highlight=(unique)|(key) In this case, since you're tokenizing, your "query" field is

Re: Strange behavior

On Feb 12, 2008 9:50 AM, Traut <[EMAIL PROTECTED]> wrote: > Thank you, it works. Stemming filter works only with lowercased words? I've never tried it in the order you have it. You could try the analysis admin page and report back what happens... -Yonik > On Feb 12, 2008 4:29 PM, Yonik Seeley <

Re: Strange behavior

Thank you, it works. Stemming filter works only with lowercased words? On Feb 12, 2008 4:29 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > Try putting the stemmer after the lowercase filter. > -Yonik > > On Feb 12, 2008 9:15 AM, Traut <[EMAIL PROTECTED]> wrote: > > Hi all > > > > Please take a loo

Re: Strange behavior

Try putting the stemmer after the lowercase filter. -Yonik On Feb 12, 2008 9:15 AM, Traut <[EMAIL PROTECTED]> wrote: > Hi all > > Please take a look at this strange behavior (connected with stemming I > suppose): > > > type: > > stored="false"> > > > > >

Re: Strange behavior MoreLikeThis Feature

Thanks Ryan. I now know the reason why. Before I explain the reason, let me correct the mistake I made in my earlier mail. I was not using the first document mentioned in the xml . Instead it was this one: IW-02 iPod & iPod Mini USB 2.0 Cable Belkin electronics connector car power adap

Re: Strange behavior MoreLikeThis Feature

Now when I run the following query: http://localhost:8080/solr/mlt?q=id:neardup06&mlt.fl=features&mlt.mindf=1&mlt.mintf=1&mlt.displayTerms=details&wt=json&indent=on try adding: &debugQuery=on to your query string and you can see why each document matches... My guess is that "features" uses

RE: Strange behavior when searching with accents

most common regular verbs. And then a custom stemmer would do the basics like adjective-mente -> adjective. Lance -Original Message- From: Thorsten Scherler [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 12:08 AM To: solr-user@lucene.apache.org Subject: RE: Strange behav

RE: Strange behavior when searching with accents

t: Thursday, September 20, 2007 8:11 AM > To: solr-user@lucene.apache.org > Subject: Re: Strange behavior when searching with accents > > On 9/20/07, Thorsten Scherler <[EMAIL PROTECTED]> > wrote: > > ...Betrand, does the French Snowball work fine?... > > I'v

RE: Strange behavior when searching with accents

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bertrand Delacretaz Sent: Thursday, September 20, 2007 8:11 AM To: solr-user@lucene.apache.org Subject: Re: Strange behavior when searching with accents On 9/20/07, Thorsten Scherler <[EMAIL PROTECTED]>

Re: Strange behavior when searching with accents

On 9/20/07, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > ...Betrand, does the French Snowball work fine?... I've seen some weirdnesses, like "tennis" and "tenir" (means to hold) both stemmed to "ten", but in all of our (simple) tests it was ok. The application where we're using it does not requ

Re: Strange behavior when searching with accents

On Thu, 2007-09-20 at 15:27 +0200, Bertrand Delacretaz wrote: > On 9/20/07, Thierry Collogne <[EMAIL PROTECTED]> wrote: > > > ...Thank you very much. Moving the up in the chain fixed it > > Yes, the problem was the EnglishPorterFilterFactory before the accents > removal: the stemmer doesn't

Re: Strange behavior when searching with accents

We are indexing both french and dutch. I will take a look at SnowballPorterFilterFactory later, but thanks for the advice. On 20/09/2007, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > On 9/20/07, Thierry Collogne <[EMAIL PROTECTED]> wrote: > > > ...Thank you very much. Moving the up in the c

Re: Strange behavior when searching with accents

On 9/20/07, Thierry Collogne <[EMAIL PROTECTED]> wrote: > ...Thank you very much. Moving the up in the chain fixed it Yes, the problem was the EnglishPorterFilterFactory before the accents removal: the stemmer doesn't know about accents, so no stemming occured on "matthé" whereas "matthe" wa

Re: Strange behavior when searching with accents

Thorsten, Thank you very much. Moving the up in the chain fixed it. On 20/09/2007, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-09-20 at 14:01 +0200, Thierry Collogne wrote: > > I have entered the the matthé term in the the analyzer, but as far as I > > understand, it should be

Re: Strange behavior when searching with accents

On Thu, 2007-09-20 at 14:01 +0200, Thierry Collogne wrote: > I have entered the the matthé term in the the analyzer, but as far as I > understand, it should be ok. I have made some screenshots with the results. > > http://farm2.static.flickr.com/1407/1412619772_0b697789cd_o.jpg > > http://farm2.s

Re: Strange behavior when searching with accents

On Thu, 2007-09-20 at 13:33 +0200, Thierry Collogne wrote: > We are using this schema definition > Thierry, try to move the solr.ISOLatin1AccentFilterFactory up the filter cue, like: ... ... for both indexing and query. This way you make sure that all accent are gone before you do further

Re: Strange behavior when searching with accents

I have entered the the matthé term in the the analyzer, but as far as I understand, it should be ok. I have made some screenshots with the results. http://farm2.static.flickr.com/1407/1412619772_0b697789cd_o.jpg http://farm2.static.flickr.com/1245/1412619774_3351b287bc_o.jpg I find it strange th

Re: Strange behavior when searching with accents

We are using this schema definition I will take a look at the analyzer took. Thank you both for the quick response. O

Re: Strange behavior when searching with accents

On 9/20/07, Thierry Collogne <[EMAIL PROTECTED]> wrote: > ..when we search for "matthé" or for "matthe", we get two totally > different results The analyzer admin tool should help you find out what's happening, see http://wiki.apache.org/solr/FAQ#head-b25df8c8393bbcca28f1f344c432975002e29ca9

Re: Strange behavior when searching with accents

On Thu, 2007-09-20 at 10:11 +0200, Thierry Collogne wrote: > Hello, > > We are experiencing some strange behavior while searching with words > containing accents. > We are using two examples "rené" and "matthé" > > When we search for "rené" or for "rene", we get the same results, so that is > ok.