Behaviour change of Query.parse(String query) in 8.7.0 vs 2.9.4
Hello Team, Recently we have started upgrading our Lucene core libraries to version 8.7.0 from v2.9.4. Some of our tests started failing which were searching on a keyword in the format 'abc-def_1-2014'. In v2.9.4 this was parsed into a Phrase query with 3 terms "abc", "def_1" and "2014" respectively. We are using a CharTokenizer to create the terms. So once we use this query to search in the index it fetches documents which have all of these terms. Hence we were getting the expected results. After we upgraded to 8.7.0 we started getting more results than expected. While investigating we found that in 8.7.0 the default query returned by Query.parse() method is Boolean Query. Hence the above keyword gets tokenized and 3 boolean clauses are created with occur as SHOULD. Hence the searcher gives us all the documents which has a matching term out of "abc", "def_1" and "2014". Hence we get more documents than what was expected earlier. Please help with this how to look for exact match. -- Sent from: https://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Behaviour change of Query.parse(String query) in 8.7.0 vs 2.9.4
Hello Team, Recently we have started upgrading our Lucene core libraries to version 8.7.0 from v2.9.4. Some of our tests started failing which were searching on a keyword in the format 'abc-def_1-2014'. In v2.9.4 this was parsed into a Phrase query with 3 terms "abc", "def_1" and "2014" respectively. We are using a CharTokenizer to create the terms. So once we use this query to search in the index it fetches documents which have all of these terms. Hence we were getting the expected results. After we upgraded to 8.7.0 we started getting more results than expected. While investigating we found that in 8.7.0 the default query returned by Query.parse() method is Boolean Query. Hence the above keyword gets tokenized and 3 boolean clauses are created with occur as SHOULD. Hence the searcher gives us all the documents which has a matching term out of "abc", "def_1" and "2014". Hence we get more documents than what was expected earlier. Please help with this how to look for exact match. -- Sent from: https://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: package-tgz-src / package-src-tgz equivilent missing from gradle build on master?
It wasn't as much of an oversight as lack of knowledge how to deal with it. I personally think the source distribution should be equivalent to a clean git checkout. If this works for you then things are relatively simple and I can do it. Dawid On Wed, Feb 3, 2021 at 1:30 AM Chris Hostetter wrote: > > > thinking about how we (want to) build solr docker containers moving > forward (SOLR-15102) lead me to realize that on the mster branch, there > doesn't seem to be any logic to build the "*-src.tgz" files. > > On branch_8x "ant package" in both the lucene & solr directories handles > this by delegation to either package-tgz-src or package-src-tgz (for some > reason they have diff names in each dir?) ... but there doesn't seem to be > any equivilent of this logic in the gradle build. > > Was this an oversight, or is ther some other plan for where/how we deal > with "src.tgz" release artifacts in 9.x ? > > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr ClusterEventProducerTest failures
There’s a ton of discussion on https://issues.apache.org/jira/browse/SOLR-15122, feel free to annotate it if you feel that isn’t moving fast enough. On Tue, Feb 2, 2021 at 8:35 PM David Smiley wrote: > This test, ClusterEventProducerTest, has been failing over 20% of the > time. Is anyone working on fixing it? Andrzej? It should be BadApple'd > ASAP if it won't be fixed soon. > > > http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cluster.events.ClusterEventProducerTest.testEvents > > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
Solr ClusterEventProducerTest failures
This test, ClusterEventProducerTest, has been failing over 20% of the time. Is anyone working on fixing it? Andrzej? It should be BadApple'd ASAP if it won't be fixed soon. http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cluster.events.ClusterEventProducerTest.testEvents ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
package-tgz-src / package-src-tgz equivilent missing from gradle build on master?
thinking about how we (want to) build solr docker containers moving forward (SOLR-15102) lead me to realize that on the mster branch, there doesn't seem to be any logic to build the "*-src.tgz" files. On branch_8x "ant package" in both the lucene & solr directories handles this by delegation to either package-tgz-src or package-src-tgz (for some reason they have diff names in each dir?) ... but there doesn't seem to be any equivilent of this logic in the gradle build. Was this an oversight, or is ther some other plan for where/how we deal with "src.tgz" release artifacts in 9.x ? -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
