[jira] [Commented] (LUCENE-10510) Check module access prior to running gjf/spotless/errorprone tasks
[ https://issues.apache.org/jira/browse/LUCENE-10510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521543#comment-17521543 ] Alan Woodward commented on LUCENE-10510: Aha, it's the nightly runs that are failing (`./gradlew -Dtests.nightly=true clean test) which I guess is running errorprone as well? I'll add a `localSettings` call first to generate the exports properly. Thanks! > Check module access prior to running gjf/spotless/errorprone tasks > -- > > Key: LUCENE-10510 > URL: https://issues.apache.org/jira/browse/LUCENE-10510 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 9.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > PR at: [https://github.com/apache/lucene/pull/802] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta opened a new pull request, #811: Add some basic tasks to help/workflow
mocobeta opened a new pull request, #811: URL: https://github.com/apache/lucene/pull/811 They might be worth adding to `help/workflow.txt`, and to me, it'd be great if we make this file a single entry point for every developer. e.g., we can just add a link to it from https://github.com/apache/lucene/blob/main/CONTRIBUTING.md instead of explaining each grade command to readers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mikemccand commented on a diff in pull request #762: LUCENE-10482 Allow users to create their own DirectoryTaxonomyReaders with empty taxoArrays instead of letting the taxoEpoch deci
mikemccand commented on code in PR #762:
URL: https://github.com/apache/lucene/pull/762#discussion_r849373865
##
lucene/facet/src/test/org/apache/lucene/facet/taxonomy/directory/TestAlwaysRefreshDirectoryTaxonomyReader.java:
##
@@ -0,0 +1,202 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.facet.taxonomy.directory;
+
+import static com.carrotsearch.randomizedtesting.RandomizedTest.sleep;
+import static org.apache.lucene.tests.mockfile.ExtrasFS.isExtra;
+
+import java.io.IOException;
+import java.nio.file.Path;
+import java.time.Instant;
+import java.util.List;
+import java.util.function.Function;
+import org.apache.lucene.facet.FacetTestCase;
+import org.apache.lucene.facet.FacetsCollector;
+import org.apache.lucene.facet.FacetsConfig;
+import org.apache.lucene.facet.taxonomy.FacetLabel;
+import org.apache.lucene.facet.taxonomy.SearcherTaxonomyManager;
+import org.apache.lucene.index.DirectoryReader;
+import org.apache.lucene.index.IndexWriterConfig;
+import org.apache.lucene.store.Directory;
+import org.apache.lucene.store.IOContext;
+import org.apache.lucene.tests.util.TestUtil;
+import org.apache.lucene.util.IOUtils;
+import org.junit.Assume;
+import org.junit.AssumptionViolatedException;
+
+public class TestAlwaysRefreshDirectoryTaxonomyReader extends FacetTestCase {
+
+ /**
+ * Tests the behavior of the {@link AlwaysRefreshDirectoryTaxonomyReader} by
testing if the
+ * associated {@link SearcherTaxonomyManager} can successfully refresh and
serve queries if the
+ * underlying taxonomy index is changed to an older checkpoint. Ideally,
each checkpoint should be
+ * self-sufficient and should allow serving search queries when {@link
+ * SearcherTaxonomyManager#maybeRefresh()} is called.
+ *
+ * It does not check whether the private taxoArrays were actually
recreated or no. We are
+ * (correctly) hiding away that complexity away from the user.
+ */
+ private void testAlwaysRefreshDirectoryTaxonomyReader(
+ Function dtrProducer, Class
exceptionType)
+ throws IOException {
+final Path taxoPath1 = createTempDir(String.valueOf(Instant.now()));
+final Directory dir1 = newFSDirectory(taxoPath1);
+try {
+ Assume.assumeFalse(
Review Comment:
if you move this `Assume` statement up to the very start of the test (before
opening `Directory` etc.) then you don't need the `try`/`finally` wrapping
around it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta commented on pull request #811: Add some basic tasks to help/workflow
mocobeta commented on PR #811: URL: https://github.com/apache/lucene/pull/811#issuecomment-1097940536 @dweiss would you mind taking a look at this? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10274) Implement "hyperrectangle" faceting
[
https://issues.apache.org/jira/browse/LUCENE-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521784#comment-17521784
]
Marc D'Mello commented on LUCENE-10274:
---
I am interested in this issue and would like to work on this.
> Implement "hyperrectangle" faceting
> ---
>
> Key: LUCENE-10274
> URL: https://issues.apache.org/jira/browse/LUCENE-10274
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/facet
>Reporter: Greg Miller
>Priority: Minor
>
> I'd be interested in expanding Lucene's faceting capabilities to aggregate a
> point field against a set of user-provided n-dimensional
> [hyperrectangles|https://en.wikipedia.org/wiki/Hyperrectangle]. This would be
> a generalization of {{LongRangeFacets}} / {{DoubleRangeFacets}} from a single
> dimension to n-dimensions, and would compliment {{PointRangeQuery}} well,
> providing the ability to facet ahead of "drilling down" on such a query.
> As a motivating use-case, imagine searching against movie documents that
> contain a 2-dimensional point storing "awards" the movie has received. One
> dimension encodes the year the award was won, while the other encodes the
> type of award as an ordinal. For example, the film "Nomadland" won the
> "Academy Awards Best Picture" award in 2021. Imagine providing a
> two-dimensional refinement to users allowing them to filter by the
> combination of award + year in a single action (e.g., using
> {{{}PointRangeQuery{}}}) and needing to get facet counts for these
> combinations ahead of time.
> Curious if the community thinks this functionality would be useful. Any
> thoughts?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] HoustonPutman commented on pull request #523: LUCENE-10293: adds a stand-alone prepareSonatypeBundle that compiles …
HoustonPutman commented on PR #523: URL: https://github.com/apache/lucene/pull/523#issuecomment-1098274229 Hey @dweiss I am finishing up the Solr 9.0.0 release and ran into this issue. It looks like both Lucene 9.0 and 9.1 used the ant command from 8.11 to do the maven upload. I tried using this method but unfortunately when you do the "upload bundle" there's a bug where it will add additional folder levels to the artifacts that you are uploading (if you have multiple artifacts included). I tried all possible ways I could think of around this, but nothing resulted in a correct repository. After lots of looking, I found out that Spark has completely automated this part of their build: https://github.com/apache/spark/blob/v3.2.1/dev/create-release/release-build.sh So I am building a script and releaseWizard entry to do this for Solr. Will happily port it to lucene afterwards. Quick question though, do you think we should create the staging repository as a part of the release candidate, then delete it/promote it if the vote succeeds? If we did that, then we wouldn't have to add the maven artifacts to the release-candidate dist folder, and users could access the maven artifacts in a more natural way. I haven't used the staging repositories myself before, so I'm not sure if this is a good idea or not. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] gautamworah96 commented on a diff in pull request #762: LUCENE-10482 Allow users to create their own DirectoryTaxonomyReaders with empty taxoArrays instead of letting the taxoEpoch d
gautamworah96 commented on code in PR #762:
URL: https://github.com/apache/lucene/pull/762#discussion_r849730444
##
lucene/facet/src/test/org/apache/lucene/facet/taxonomy/directory/TestAlwaysRefreshDirectoryTaxonomyReader.java:
##
@@ -0,0 +1,202 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.facet.taxonomy.directory;
+
+import static com.carrotsearch.randomizedtesting.RandomizedTest.sleep;
+import static org.apache.lucene.tests.mockfile.ExtrasFS.isExtra;
+
+import java.io.IOException;
+import java.nio.file.Path;
+import java.time.Instant;
+import java.util.List;
+import java.util.function.Function;
+import org.apache.lucene.facet.FacetTestCase;
+import org.apache.lucene.facet.FacetsCollector;
+import org.apache.lucene.facet.FacetsConfig;
+import org.apache.lucene.facet.taxonomy.FacetLabel;
+import org.apache.lucene.facet.taxonomy.SearcherTaxonomyManager;
+import org.apache.lucene.index.DirectoryReader;
+import org.apache.lucene.index.IndexWriterConfig;
+import org.apache.lucene.store.Directory;
+import org.apache.lucene.store.IOContext;
+import org.apache.lucene.tests.util.TestUtil;
+import org.apache.lucene.util.IOUtils;
+import org.junit.Assume;
+import org.junit.AssumptionViolatedException;
+
+public class TestAlwaysRefreshDirectoryTaxonomyReader extends FacetTestCase {
+
+ /**
+ * Tests the behavior of the {@link AlwaysRefreshDirectoryTaxonomyReader} by
testing if the
+ * associated {@link SearcherTaxonomyManager} can successfully refresh and
serve queries if the
+ * underlying taxonomy index is changed to an older checkpoint. Ideally,
each checkpoint should be
+ * self-sufficient and should allow serving search queries when {@link
+ * SearcherTaxonomyManager#maybeRefresh()} is called.
+ *
+ * It does not check whether the private taxoArrays were actually
recreated or no. We are
+ * (correctly) hiding away that complexity away from the user.
+ */
+ private void testAlwaysRefreshDirectoryTaxonomyReader(
+ Function dtrProducer, Class
exceptionType)
+ throws IOException {
+final Path taxoPath1 = createTempDir(String.valueOf(Instant.now()));
+final Directory dir1 = newFSDirectory(taxoPath1);
+try {
+ Assume.assumeFalse(
Review Comment:
I'm not sure if i am missing something. I don't see a method that just
disables the test from creating `WindowsFS` FS and the functions to check if
the `dir` uses `WindowsFS` takes the `dir` as an input?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10510) Check module access prior to running gjf/spotless/errorprone tasks
[ https://issues.apache.org/jira/browse/LUCENE-10510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521850#comment-17521850 ] Dawid Weiss commented on LUCENE-10510: -- I suspected it might have been the nightly runs. We could try to detect whether the JVM would run with an unexported jdk package (anything up until jdk16?) but I think it buries the problem rather than solves it. I think it's easy to run a first pass that generates those required JVM settings. If you for some reason can't do it, pass them via command-line (or environment variables) directly to gradle - https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_environment_variables this will also work, even in the absence of gradle.properties, as the task verifies whether the required modules are open (not how or where they were opened). Sorry for the complications - not my fault. :) > Check module access prior to running gjf/spotless/errorprone tasks > -- > > Key: LUCENE-10510 > URL: https://issues.apache.org/jira/browse/LUCENE-10510 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 9.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > PR at: [https://github.com/apache/lucene/pull/802] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #808: LUCENE-10513: Run `gradlew tidy` first
dweiss commented on PR #808: URL: https://github.com/apache/lucene/pull/808#issuecomment-1098327441 LGTM, thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on a diff in pull request #811: Add some basic tasks to help/workflow
dweiss commented on code in PR #811: URL: https://github.com/apache/lucene/pull/811#discussion_r849753568 ## help/workflow.txt: ## @@ -25,11 +25,22 @@ Assemble a single module's JAR (here for lucene-core): gradlew -p lucene/core assemble ls lucene/core/build/libs +Assemble all JARs: +gradlew assemble + Create all distributable packages, POMs, etc. and create a local maven repository for inspection: gradlew mavenLocal ls -R build/maven-local/ +Assemble Javdocs on a module: Review Comment: This is a general question on where to explain how gradle works (-p command) and whether this document should provide ready-to-use commands doing things or an explanation how to assemble those commands from scratch. I'm not sure how much people are willing to read about gradle... :) Separately - do you ever assemble javadocs for a single module? What's the point of doing that? ## help/workflow.txt: ## @@ -25,11 +25,22 @@ Assemble a single module's JAR (here for lucene-core): gradlew -p lucene/core assemble ls lucene/core/build/libs +Assemble all JARs: Review Comment: This convention task is for assembling... well, things that need to be assembled. It's not just JARs but typically also other stuff (say, the documentation could be assembled from sources). I'm not sure if it makes a difference but perhaps it's worth clarifying here? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #523: LUCENE-10293: adds a stand-alone prepareSonatypeBundle that compiles …
dweiss commented on PR #523: URL: https://github.com/apache/lucene/pull/523#issuecomment-1098339324 > I tried using this method but unfortunately when you do the "upload bundle" there's a bug where it will add additional folder levels to the artifacts that you are uploading (if you have multiple artifacts included). I tried all possible ways I could think of around this, but nothing resulted in a correct repository. I mentioned this somewhere, actually (and I provided a patch that did prepare the correct bundle structure). I'm not sure where this was and I have limited internet connectivity so I can't look it up... but I think it's here: https://issues.apache.org/jira/browse/LUCENE-9488 Anyway. We already publish maven artifacts to nexus (snapshots). And the code to publish to releases is already there too -- see maven-to-nexus-releases.gradle and "mavenToApacheReleases" task. Why not just use this instead of some odd sh scripts? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] HoustonPutman commented on pull request #523: LUCENE-10293: adds a stand-alone prepareSonatypeBundle that compiles …
HoustonPutman commented on PR #523: URL: https://github.com/apache/lucene/pull/523#issuecomment-1098479631 I'm fairly confused. The `mavenToApacheReleases` task was authored in October of last year, while this PR is from December, so I assumed that there was an effort to solve this beyond using `mavenToApacheReleases`. Is this PR trying to tackle a different task than I think it is? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #523: LUCENE-10293: adds a stand-alone prepareSonatypeBundle that compiles …
dweiss commented on PR #523: URL: https://github.com/apache/lucene/pull/523#issuecomment-1098488535 Sorry. Working from remote/ holidays and only having 5 minutes to look at things. So the sonatype bundle should be working fine, really. I know about the problem with subfolders but I did have it working in other projects and I think it should be working here as well? Spark's solution seems terribly long and complicated to me (not to mention it's not really playing nice with Windows users, for example). I'd rather have it assemble a (portable) bundle in a portable way. The problem, as far as I remember, was that the release process requires the same artifacts to be voted upon and then published. When you prepare a bundle, everything has to be flattened into a single level - this is a source of pain when reviewing artifacts for publication. And that's why you can't really use gradle's built-in mechanism of uploading artifacts (because they would/could be different on each gradle build from scratch). If we can live with a flatttened bundle though, it should be fairly easy to implement the release process around it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss commented on pull request #523: LUCENE-10293: adds a stand-alone prepareSonatypeBundle that compiles …
dweiss commented on PR #523:
URL: https://github.com/apache/lucene/pull/523#issuecomment-1098490488
When you tried uploading the bundle, did you use this patch, @HoustonPutman
? Because it does "flatten" the artifact structure -
```
eachFile { FileCopyDetails details ->
details.path = details.name
}
```
and I recall I tried it with Apache Nexus and it seemed to work just fine.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] gautamworah96 commented on a diff in pull request #762: LUCENE-10482 Allow users to create their own DirectoryTaxonomyReaders with empty taxoArrays instead of letting the taxoEpoch d
gautamworah96 commented on code in PR #762:
URL: https://github.com/apache/lucene/pull/762#discussion_r849963313
##
lucene/facet/src/test/org/apache/lucene/facet/taxonomy/directory/TestAlwaysRefreshDirectoryTaxonomyReader.java:
##
@@ -0,0 +1,202 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.facet.taxonomy.directory;
+
+import static com.carrotsearch.randomizedtesting.RandomizedTest.sleep;
+import static org.apache.lucene.tests.mockfile.ExtrasFS.isExtra;
+
+import java.io.IOException;
+import java.nio.file.Path;
+import java.time.Instant;
+import java.util.List;
+import java.util.function.Function;
+import org.apache.lucene.facet.FacetTestCase;
+import org.apache.lucene.facet.FacetsCollector;
+import org.apache.lucene.facet.FacetsConfig;
+import org.apache.lucene.facet.taxonomy.FacetLabel;
+import org.apache.lucene.facet.taxonomy.SearcherTaxonomyManager;
+import org.apache.lucene.index.DirectoryReader;
+import org.apache.lucene.index.IndexWriterConfig;
+import org.apache.lucene.store.Directory;
+import org.apache.lucene.store.IOContext;
+import org.apache.lucene.tests.util.TestUtil;
+import org.apache.lucene.util.IOUtils;
+import org.junit.Assume;
+import org.junit.AssumptionViolatedException;
+
+public class TestAlwaysRefreshDirectoryTaxonomyReader extends FacetTestCase {
+
+ /**
+ * Tests the behavior of the {@link AlwaysRefreshDirectoryTaxonomyReader} by
testing if the
+ * associated {@link SearcherTaxonomyManager} can successfully refresh and
serve queries if the
+ * underlying taxonomy index is changed to an older checkpoint. Ideally,
each checkpoint should be
+ * self-sufficient and should allow serving search queries when {@link
+ * SearcherTaxonomyManager#maybeRefresh()} is called.
+ *
+ * It does not check whether the private taxoArrays were actually
recreated or no. We are
+ * (correctly) hiding away that complexity away from the user.
+ */
+ private void testAlwaysRefreshDirectoryTaxonomyReader(
+ Function dtrProducer, Class
exceptionType)
+ throws IOException {
+final Path taxoPath1 = createTempDir(String.valueOf(Instant.now()));
+final Directory dir1 = newFSDirectory(taxoPath1);
+try {
+ Assume.assumeFalse(
Review Comment:
Added an cleaner annotation in
[5027eb5](https://github.com/apache/lucene/pull/762/commits/5027eb56ea4d387007a712a9a21d2d06b01c801e)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] nknize commented on a diff in pull request #809: LUCENE-10514: Component2D#Within methods should return NOTWITHIN when the query geometry contains the triangle
nknize commented on code in PR #809:
URL: https://github.com/apache/lucene/pull/809#discussion_r850050047
##
lucene/core/src/java/org/apache/lucene/geo/Polygon2D.java:
##
@@ -257,10 +257,13 @@ public WithinRelation withinLine(
boolean ab,
double bX,
double bY) {
-if (ab == true
Review Comment:
Something feels off about this though (albeit, it's been a while since I
touched this part of the code), `ab` is intended to identify an edge shared
with the "original" geometry. We shouldn't care about the relation of the
Polygon2D object to tessellation edges when computing a within relation?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] iverase commented on a diff in pull request #809: LUCENE-10514: Component2D#Within methods should return NOTWITHIN when the query geometry contains the triangle
iverase commented on code in PR #809:
URL: https://github.com/apache/lucene/pull/809#discussion_r850084313
##
lucene/core/src/java/org/apache/lucene/geo/Polygon2D.java:
##
@@ -257,10 +257,13 @@ public WithinRelation withinLine(
boolean ab,
double bX,
double bY) {
-if (ab == true
Review Comment:
That's the point of this issue. We need to care because we need to
distinguish between triangles that are fully inside the query geometry as those
ones needs to be reported as not within. Therefore we need to check if any of
the points is inside.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
