[jira] [Updated] (LUCENE-9623) Add module descriptor (module-info.java) to lucene jars
[ https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-9623: -- Description: For a starter, module descriptors can be automatically generated by jdeps utility. There are two choices. 1. generate "open" modules which allows reflective accesses with --generate-open-module option 2. generate non-open modules with --generate-module-info option Which is the better - not fully sure, but maybe 2 (non-open modules)? Also, we need to choose proper module names - just using gradle project path for it is OK? was: For a starter, module descriptors can be automatically generated by jdeps utility. There are two choices. 1. generate "open" modules which allows reflective accesses with --generate-open-module option 2. generate non-open modules with --generate-module-info option Which is the better - not fully sure, but maybe 2 (non-open modules)? Also, we need to choose proper module names - just using the artifact (jar) name for it is OK? > Add module descriptor (module-info.java) to lucene jars > --- > > Key: LUCENE-9623 > URL: https://issues.apache.org/jira/browse/LUCENE-9623 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Priority: Major > Attachments: generate-all-module-info.sh > > > For a starter, module descriptors can be automatically generated by jdeps > utility. > There are two choices. > 1. generate "open" modules which allows reflective accesses with > --generate-open-module option > 2. generate non-open modules with --generate-module-info option > Which is the better - not fully sure, but maybe 2 (non-open modules)? > Also, we need to choose proper module names - just using gradle project path > for it is OK? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9623) Add module descriptor (module-info.java) to lucene jars
[ https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240195#comment-17240195 ] Tomoko Uchida commented on LUCENE-9623: --- Fortunately, jdeps seems to work almost fine for me (except for the benchmark module). In regards to Gradle build, this plugin seems to be needed. [https://docs.gradle.org/current/samples/sample_java_modules_multi_project.html] Also I think we'd need to consider a way to keep the module descriptors up-to-date... [~dweiss] and [~uschindler], would you give me some feedback? > Add module descriptor (module-info.java) to lucene jars > --- > > Key: LUCENE-9623 > URL: https://issues.apache.org/jira/browse/LUCENE-9623 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Priority: Major > Attachments: generate-all-module-info.sh > > > For a starter, module descriptors can be automatically generated by jdeps > utility. > There are two choices. > 1. generate "open" modules which allows reflective accesses with > --generate-open-module option > 2. generate non-open modules with --generate-module-info option > Which is the better - not fully sure, but maybe 2 (non-open modules)? > Also, we need to choose proper module names - just using gradle project path > for it is OK? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9623) Add module descriptor (module-info.java) to lucene jars
[ https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240206#comment-17240206 ] Dawid Weiss commented on LUCENE-9623: - Hi Tomoko. I think you could use gradle itself to generate that module-info (even if it's temporary) - it'd be easier to collect dependencies, etc? If you ask me, I'd generate explicit exports (not open modules). This way encapsulation is enforced from the start and there is no need to backtrack later. Other than that I really have no idea how to work with the module system at the build level - this is uncharted territory. Makes me think if we shouldn't wait until the build is split into Solr and Lucene - Lucene treated independently seems to be easier than combined with Solr's dependencies. > Add module descriptor (module-info.java) to lucene jars > --- > > Key: LUCENE-9623 > URL: https://issues.apache.org/jira/browse/LUCENE-9623 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Priority: Major > Attachments: generate-all-module-info.sh > > > For a starter, module descriptors can be automatically generated by jdeps > utility. > There are two choices. > 1. generate "open" modules which allows reflective accesses with > --generate-open-module option > 2. generate non-open modules with --generate-module-info option > Which is the better - not fully sure, but maybe 2 (non-open modules)? > Also, we need to choose proper module names - just using gradle project path > for it is OK? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9623) Add module descriptor (module-info.java) to lucene jars
[
https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240217#comment-17240217
]
Tomoko Uchida commented on LUCENE-9623:
---
{quote}I think you could use gradle itself to generate that module-info (even
if it's temporary) - it'd be easier to collect dependencies, etc?
{quote}
In theory I think it should be possible. First we assemble a not-modularized
JAR, then generate module-info.java for it by jdeps tool, then compile the
generated module-info.java, and finally update the existing JAR with the
compiled module-info.class. (As a side note, this is not my idea but it's the
exact migration procedure to modules I read in [a
book|https://javamodularity.com/] a moment ago.) We could do it with custom
gradle tasks, instead of shell scripts.
{quote}If you ask me, I'd generate explicit exports (not open modules). This
way encapsulation is enforced from the start and there is no need to backtrack
later.
{quote}
I'm also in favor of it.
> Add module descriptor (module-info.java) to lucene jars
> ---
>
> Key: LUCENE-9623
> URL: https://issues.apache.org/jira/browse/LUCENE-9623
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Priority: Major
> Attachments: generate-all-module-info.sh
>
>
> For a starter, module descriptors can be automatically generated by jdeps
> utility.
> There are two choices.
> 1. generate "open" modules which allows reflective accesses with
> --generate-open-module option
> 2. generate non-open modules with --generate-module-info option
> Which is the better - not fully sure, but maybe 2 (non-open modules)?
> Also, we need to choose proper module names - just using gradle project path
> for it is OK?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on pull request #2088: LUCENE-9617: Reset lowestUnassignedFieldNumber in FieldNumbers.clear()
mikemccand commented on pull request #2088:
URL: https://github.com/apache/lucene-solr/pull/2088#issuecomment-735405583
Great, thank you for adding the new "user space impact" test case @msfroh
(in addition to the low-level unit test)! @dsmiley does that address your
concern about the lower level unit test?
Net/net I think this is ready -- I think the existing tests we have that
concurrently {{deleteAll}} help address @rmuir's concern too. I will beast
this change for a while to see if there are any interesting failures ...
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.
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-solr] mikemccand commented on a change in pull request #2097: LUCENE-9537
mikemccand commented on a change in pull request #2097:
URL: https://github.com/apache/lucene-solr/pull/2097#discussion_r532220806
##
File path: lucene/core/src/java/org/apache/lucene/search/CachingCollector.java
##
@@ -59,6 +59,11 @@
@Override
public final float score() { return score; }
+@Override
+public float smoothingScore(int docId) throws IOException {
+ return 0;
Review comment:
Hmm, should we also cache the `smoothingScore` for this hit?
Or, if we will keep it at returning `0`, couldn't we remove this impl and
inherit the default from `Scorable`?
##
File path: lucene/core/src/java/org/apache/lucene/search/IndriAndScorer.java
##
@@ -0,0 +1,59 @@
+package org.apache.lucene.search;
+
+import java.io.IOException;
+import java.util.List;
+
+/** Combines scores of subscorers. If a subscorer does not contain
+ * the docId, a smoothing score is calculated for that
+ * document/subscorer combination.
+ */
+public class IndriAndScorer extends IndriDisjunctionScorer {
Review comment:
Do we expect to have other scorers that need to extend the
`IndriDisjunctionScorer`? Here we have only one such subclass, so I wonder if
we could just fold all of this into a single `IndriDisjunctionScorer` class?
Or, are you laying bedrock for future additional query types?
##
File path: lucene/core/src/java/org/apache/lucene/search/FilterScorable.java
##
@@ -46,6 +46,11 @@ public float score() throws IOException {
return in.score();
}
+ @Override
+ public float smoothingScore(int docId) throws IOException {
+return 0;
Review comment:
Hmm should this be `return in.smoothingScore(docId)` instead?
##
File path: lucene/core/src/java/org/apache/lucene/search/IndriAndQuery.java
##
@@ -0,0 +1,22 @@
+package org.apache.lucene.search;
+
+import java.io.IOException;
+import java.util.List;
+
+/** A Query that matches documents matching combinations of
+ * {@link TermQuery}s or other IndriAndQuerys.
+ */
+public class IndriAndQuery extends IndriQuery {
+
+ public IndriAndQuery(List clauses) {
Review comment:
In general, `BooleanClause` can hold any Lucene `Query` implementation,
but it looks like we are only supporting `TermQuery` and other `IndriAndQuery`
clauses (just from reading the javadoc)? If so, should we check/enforce this?
##
File path: lucene/core/src/java/org/apache/lucene/search/IndriAndQuery.java
##
@@ -0,0 +1,22 @@
+package org.apache.lucene.search;
Review comment:
Could you add the standard Apache copyright header here and in all the
new classes?
##
File path: lucene/core/src/java/org/apache/lucene/search/IndriAndScorer.java
##
@@ -0,0 +1,59 @@
+package org.apache.lucene.search;
+
+import java.io.IOException;
+import java.util.List;
+
+/** Combines scores of subscorers. If a subscorer does not contain
+ * the docId, a smoothing score is calculated for that
+ * document/subscorer combination.
+ */
+public class IndriAndScorer extends IndriDisjunctionScorer {
+
+ protected IndriAndScorer(Weight weight, List subScorers,
+ ScoreMode scoreMode, float boost) throws IOException {
+super(weight, subScorers, scoreMode, boost);
+ }
+
+ @Override
+ public float score(List subScorers) throws IOException {
+int docId = this.docID();
+return scoreDoc(subScorers, docId);
+ }
+
+ @Override
+ public float smoothingScore(List subScorers, int docId)
+ throws IOException {
+return scoreDoc(subScorers, docId);
+ }
+
+ private float scoreDoc(List subScorers, int docId)
+ throws IOException {
+double score = 0;
+double boostSum = 0.0;
+for (Scorer scorer : subScorers) {
+ if (scorer instanceof IndriScorer) {
+IndriScorer indriScorer = (IndriScorer) scorer;
+int scorerDocId = indriScorer.docID();
+//If the query exists in the document, score the document
+//Otherwise, compute a smoothing score, which acts like an idf
+//for subqueries/terms
+if (docId == scorerDocId) {
Review comment:
Can you factor out the 2nd two statements under each of the `true` and
`false` clauses here? I.e., only the first line needs to be conditional?
##
File path:
lucene/core/src/java/org/apache/lucene/search/IndriDisjunctionScorer.java
##
@@ -0,0 +1,65 @@
+package org.apache.lucene.search;
+
+import java.io.IOException;
+import java.util.List;
+
+/**
+ * The Indri implemenation of a disjunction scorer which stores the subscorers
+ * for for the child queries. The score and smoothingScore methods use the list
Review comment:
Remove extra `for`?
##
File path: lucene/core/src/java/org/apache/lucene/search/IndriScorer.java
##
@@ -0,0 +1,37 @@
+package org.apache.lucene.search;
+
+import java.io.IOException;
+
+/**
+ * The Indri parent scorer that stores the boost so that
+ * IndriScorers can use the
[jira] [Commented] (LUCENE-9537) Add Indri Search Engine Functionality to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-9537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240276#comment-17240276 ] Michael McCandless commented on LUCENE-9537: Thank you [~cvandenberg] – sorry for the slow response – I left a few comments on the PR. > Add Indri Search Engine Functionality to Lucene > --- > > Key: LUCENE-9537 > URL: https://issues.apache.org/jira/browse/LUCENE-9537 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Cameron VandenBerg >Priority: Major > Labels: patch > Attachments: LUCENE-9537.patch, LUCENE-INDRI.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Indri ([http://lemurproject.org/indri.php]) is an academic search engine > developed by The University of Massachusetts and Carnegie Mellon University. > The major difference between Lucene and Indri is that Indri will give a > document a "smoothing score" to a document that does not contain the search > term, which has improved the search ranking accuracy in our experiments. I > have created an Indri patch, which adds the search code needed to implement > the Indri AND logic as well as Indri's implementation of Dirichlet Smoothing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #2095: LUCENE-9618: Do not call IntervalIterator.nextInterval after NO_MORE_DOCS returned
mikemccand commented on a change in pull request #2095: URL: https://github.com/apache/lucene-solr/pull/2095#discussion_r532225098 ## File path: lucene/CHANGES.txt ## @@ -84,6 +84,8 @@ API Changes Improvements +* LUCENE-9618: Do not call IntervalIterator.nextInterval after NO_MORE_DOCS is returned Review comment: You can add your name to the end of this `CHANGES` entry (in parens)? 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. 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-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance
[ https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240342#comment-17240342 ] Mikhail Khludnev commented on LUCENE-9021: -- Ready to commit. I see PR have passed precommit check, but it the patch has conflict. I kindly appreciate if it's resolved. > QueryParser should avoid creating an LookaheadSuccess(Error) object with > every instance > --- > > Key: LUCENE-9021 > URL: https://issues.apache.org/jira/browse/LUCENE-9021 > Project: Lucene - Core > Issue Type: Bug >Reporter: Przemek Bruski >Priority: Major > Attachments: LUCENE-9021.patch > > Time Spent: 10m > Remaining Estimate: 0h > > This is basically the same as > https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-8673) o.a.s.search.facet classes not public/extendable
[
https://issues.apache.org/jira/browse/SOLR-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240343#comment-17240343
]
Mikhail Khludnev commented on SOLR-8673:
[~TimOwen], I'm steadily getting back to development. I noticed that patch
verification works only for github PR. Would you mind to move patch to github,
and link here. Thanks. Appreciate.
> o.a.s.search.facet classes not public/extendable
>
>
> Key: SOLR-8673
> URL: https://issues.apache.org/jira/browse/SOLR-8673
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 5.4.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: SOLR-8673.patch, SOLR-8673.patch
>
>
> It is not easy to create a custom JSON facet function. A simple function
> based on AvgAgg quickly results in the following compilation failures:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile)
> on project openindex-solr: Compilation failure: Compilation failure:
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[22,36]
> org.apache.solr.search.facet.FacetContext is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[23,36]
> org.apache.solr.search.facet.FacetDoubleMerger is not public in
> org.apache.solr.search.facet; cannot be accessed from outside package
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[40,32]
> cannot find symbol
> [ERROR] symbol: class FacetContext
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[49,39]
> cannot find symbol
> [ERROR] symbol: class FacetDoubleMerger
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[54,43]
> cannot find symbol
> [ERROR] symbol: class Context
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg.Merger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[41,16]
> cannot find symbol
> [ERROR] symbol: class AvgSlotAcc
> [ERROR] location: class i.o.s.search.facet.CustomAvgAgg
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[46,12]
> incompatible types: i.o.s.search.facet.CustomAvgAgg.Merger cannot be
> converted to org.apache.solr.search.facet.FacetMerger
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[53,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/markus/projects/openindex/solr/trunk/src/main/java/i.o.s.search/facet/CustomAvgAgg.java:[60,5]
> method does not override or implement a method from a supertype
> {code}
> It seems lots of classes are tucked away in FacetModule, which we can't reach
> from outside.
> Originates from this thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201602.mbox/%3ccab_8yd9ldbg_0zxm_h1igkfm6bqeypd5ilyy7tty8cztscv...@mail.gmail.com%3E
> ( also available at
> https://lists.apache.org/thread.html/9fddcad3136ec908ce1c57881f8d3069e5d153f08b71f80f3e18d995%401455019826%40%3Csolr-user.lucene.apache.org%3E
> )
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15017) The core's lib/ folder content is not loaded in the classloader anymore when the core's configuration does not define any element
[
https://issues.apache.org/jira/browse/SOLR-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240481#comment-17240481
]
David Smiley commented on SOLR-15017:
-
Hi; thanks for reporting this regression. I think it was my fault. The fix
seems straight-forward to me... basically don't exit early from this method
just because there is no {{}} in the XML. WDYT? Can you file a PR?
> The core's lib/ folder content is not loaded in the classloader anymore when
> the core's configuration does not define any element
> ---
>
> Key: SOLR-15017
> URL: https://issues.apache.org/jira/browse/SOLR-15017
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: Thomas Mortagne
>Priority: Blocker
> Labels: regression
>
> I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to
> 8.7.0 and it seems that the lib subfolder inside a core folder is not taken
> into account anymore.
> Works fine when I move the lib/ folder one level up (in the Solr home folder)
> but when the lib folder with the plugins is located in the core folder it
> cannot find any of the classes.
> I debugged it a little and I think the regression was caused by the
> refactoring done in
> https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
> : the handling of the lib/ core's sub folder was moved to
> SolrConfig#initLibs() but unfortunately the check to make sure there is at
> least one {{}} element in the configuration file was not removed which
> means that if you don't have any of those then the content of the lib/ folder
> is totally ignored.
> That debugging was easy enough but I don't know Solr internals enough to
> propose something clean to fix the issue in a pull request.
> The workaround is to make sure there is at least one {{}} element (for
> example ) in the core's
> solrconfig.xml file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-15017) The core's lib/ folder content is not loaded in the classloader anymore when the core's configuration does not define any element
[
https://issues.apache.org/jira/browse/SOLR-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley reassigned SOLR-15017:
---
Assignee: David Smiley
> The core's lib/ folder content is not loaded in the classloader anymore when
> the core's configuration does not define any element
> ---
>
> Key: SOLR-15017
> URL: https://issues.apache.org/jira/browse/SOLR-15017
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.7
>Reporter: Thomas Mortagne
>Assignee: David Smiley
>Priority: Blocker
> Labels: regression
>
> I just upgraded solr-core (I'm using Solr in embedded mode) from 8.5.1 to
> 8.7.0 and it seems that the lib subfolder inside a core folder is not taken
> into account anymore.
> Works fine when I move the lib/ folder one level up (in the Solr home folder)
> but when the lib folder with the plugins is located in the core folder it
> cannot find any of the classes.
> I debugged it a little and I think the regression was caused by the
> refactoring done in
> https://github.com/apache/lucene-solr/commit/732348ec7f9c6b6f7bf9d539a40e50d16198#diff-473fbcdab103c08461ad1b3c3bb1c6d56f1bcd16d6ce341d80855db2cb20a427R749
> : the handling of the lib/ core's sub folder was moved to
> SolrConfig#initLibs() but unfortunately the check to make sure there is at
> least one {{}} element in the configuration file was not removed which
> means that if you don't have any of those then the content of the lib/ folder
> is totally ignored.
> That debugging was easy enough but I don't know Solr internals enough to
> propose something clean to fix the issue in a pull request.
> The workaround is to make sure there is at least one {{}} element (for
> example ) in the core's
> solrconfig.xml file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15018) Atomic update deletes child documents if schema has catch-all ignore field
[
https://issues.apache.org/jira/browse/SOLR-15018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240483#comment-17240483
]
David Smiley commented on SOLR-15018:
-
FWIW, I don't recommend a "*" ignored catch-all dynamic field except maybe in
some early prototyping scenario as a sort of TODO before you lock down the
schema.
> Atomic update deletes child documents if schema has catch-all ignore field
> --
>
> Key: SOLR-15018
> URL: https://issues.apache.org/jira/browse/SOLR-15018
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update
>Affects Versions: 8.6.3
>Reporter: Andreas Hubold
>Priority: Major
> Labels: AtomicUpdate, ChildDocuments, NestedDocuments
>
> Nested child documents disappear when some unrelated fields of a parent
> document are atomically updated, if the schema contains a catch-all dynamic
> field to ignore unknown fields like:
> {noformat}
>
> class="solr.StrField" /> {noformat}
> {{DistributedUpdateProcessor#getUpdatedDocument}} tries to reconstruct the
> original document, but it does not receive nested documents from
> {{RealTimeComponent#getInputDocument}}. Nested documents are correctly found
> in the index but get lost when {{RealTimeGetComponent#toSolrInputDocument}}
> creates a SolrInputDocument for it. The problematic code is:
> {code:java}
> SchemaField sf = schema.getFieldOrNull(fname);
> if (sf != null) {
> if ((!sf.hasDocValues() && !sf.stored()) || schema.isCopyFieldTarget(sf))
> continue;
> } {code}
> The code finds the "ignored" SchemaField as matching field for the nested
> document name (loaded from _nest_path_). Because of that they're not added to
> the SolrInputDocument.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
