date:20201009

[GitHub] [lucene-solr] uschindler commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



uschindler commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-706020485


   Thanks Dawid. There's still work to do. The Lucene packaging brings a 
totally strange dependency error.
   Solr works. The only difference is configuration name. But it was too late 
yesterday.
   I will also cleanup some parts where I repeatedly used 
'project.parent.something' to get out of documentation subproject to Lucene or 
Solr main.
   But it gets closed. Once I am done it would be good to have another look.



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] dweiss commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



dweiss commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-706022783


   I only looked at the diff. If you need my help, ping me. I'm working but I 
can take a look later to see what that error 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.

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] uschindler commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



uschindler commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-706037123


   I fixed the problem with the dependency. Was some explicit exclusion of the 
"empty" subprojects. Maybe this should be changed to only collect project that 
actually have the correct configuration.



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] uschindler commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



uschindler commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-706084310


   Hi @dweiss, 
   I think all is working now. Can you have a quick look.
   
   This should also make the split between lucene and solr easier, as the 
changes2html per script and resources was moved to the `gradle/documentation` 
subdir.



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] dweiss opened a new pull request #1968: LUCENE-9562: Unify 'analysis' package with produced artifact names (-analyzers- to -analysis-)

2020-10-09 Thread GitBox



dweiss opened a new pull request #1968:
URL: https://github.com/apache/lucene-solr/pull/1968


   



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-9562) Unify 'analysis' package with produced artifact names

2020-10-09 Thread Dawid Weiss (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210781#comment-17210781
 ] 

Dawid Weiss commented on LUCENE-9562:
-

I filed a PR for this. All checks pass for me.

> Unify 'analysis' package with produced artifact names
> -
>
> Key: LUCENE-9562
> URL: https://issues.apache.org/jira/browse/LUCENE-9562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Lucene has 'analysis' module but its sub-modules produce 'lucene-analyzers-*' 
> artifacts. This inconsistency is currently handled by setting artifact names 
> manually:
> {code}
> configure(subprojects.findAll { it.path.contains(':lucene:analysis:') }) {
>   project.archivesBaseName = project.archivesBaseName.replace("-analysis-", 
> "-analyzers-")
> }
> {code}
> but I keep wondering if we should just make it one or the other - either 
> rename 'analysis' to 'analyzers' or produce 'lucene-analysis-' artifacts.
> My personal opinion is to produce 'lucene-analysis-' packages because this 
> keeps repository structure the same (backports will be easier) and we're 
> targeting a major release anyway so people can adjust dependency names when 
> upgrading. This change would be also consistent with package naming inside 
> those modules. 



--
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] dweiss commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



dweiss commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-706095367


   LGTM, Uwe.



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] uschindler commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



uschindler commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-706106009


   I also fixed the links to the new output folder in the ref guide



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] [Updated] (SOLR-14844) Upgrade Jetty to 9.4.32.v20200930

2020-10-09 Thread Erick Erickson (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-14844:
--
Summary: Upgrade Jetty to 9.4.32.v20200930  (was: Upgrade Jetty to 9.4.31)

> Upgrade Jetty to 9.4.32.v20200930
> -
>
> Key: SOLR-14844
> URL: https://issues.apache.org/jira/browse/SOLR-14844
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.6
>Reporter: Cassandra Targett
>Assignee: Erick Erickson
>Priority: Major
>
> A CVE was found in Jetty 9.4.27-9.4.29 that has some security scanning tools 
> raising red flags 
> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17638]).
> Here's the Jetty issue: 
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984]. It's fixed in 
> 9.4.30+, so we should upgrade to that for 8.7
> -It has a simple mitigation (raise Jetty's responseHeaderSize to higher than 
> requestHeaderSize), but I don't know how Solr uses Jetty well enough to a) 
> know if this problem is even exploitable in Solr, or b) if the workaround 
> suggested is even possible in Solr.-
> In normal Solr installs, w/o jetty optimizations, this issue is largely 
> mitigated in 8.6.3: see SOLR-14896 (and linked bug fixes) for details.



--
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-14844) Upgrade Jetty to 9.4.32.v20200930

2020-10-09 Thread Erick Erickson (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210874#comment-17210874
 ] 

Erick Erickson commented on SOLR-14844:
---

Coming back to this, so I'll try with the newest Jetty.

> Upgrade Jetty to 9.4.32.v20200930
> -
>
> Key: SOLR-14844
> URL: https://issues.apache.org/jira/browse/SOLR-14844
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.6
>Reporter: Cassandra Targett
>Assignee: Erick Erickson
>Priority: Major
>
> A CVE was found in Jetty 9.4.27-9.4.29 that has some security scanning tools 
> raising red flags 
> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17638]).
> Here's the Jetty issue: 
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984]. It's fixed in 
> 9.4.30+, so we should upgrade to that for 8.7
> -It has a simple mitigation (raise Jetty's responseHeaderSize to higher than 
> requestHeaderSize), but I don't know how Solr uses Jetty well enough to a) 
> know if this problem is even exploitable in Solr, or b) if the workaround 
> suggested is even possible in Solr.-
> In normal Solr installs, w/o jetty optimizations, this issue is largely 
> mitigated in 8.6.3: see SOLR-14896 (and linked bug fixes) for details.



--
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] dweiss opened a new pull request #1969: LUCENE-6831: start removing LinkedList in favor of ArrayList or De/Queues

2020-10-09 Thread GitBox



dweiss opened a new pull request #1969:
URL: https://github.com/apache/lucene-solr/pull/1969


   



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] uschindler merged pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



uschindler merged pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967


   



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-9577) Move HTML Documentation to a separate subproject

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210910#comment-17210910
 ] 

ASF subversion and git services commented on LUCENE-9577:
-

Commit 2329423e5c34c4e1d5a6d08bc8da7a09fd11d1fb in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2329423 ]

LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject (#1967)



> Move HTML Documentation to a separate subproject
> 
>
> Key: LUCENE-9577
> URL: https://issues.apache.org/jira/browse/LUCENE-9577
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Currently Lucene/Solr have some subdirectory "site" containing some fragments 
> for CHANGES.txt formatting and the Markdown to produce the site. The global 
> documentation for both Lucene and Solr should be built with its own 
> subproject {{:lucene:documentation}} and {{:solr:documentation}}.
> I will provide a PR that does the following:
> - Move Changes.html formatting scripts to gradle subfolder, so they are 
> correctly shared between Lucene and Gradle and allows to split project 
> (currently they live in Lucene only)
> - Move the site contents with correct names a {{src/assets}}, 
> {{src/markdown}} into the new documentation projects
> - Make packaging of documentation in the projects build.gradle. 
> {{:lucene:documentation:assemble}} should assemble the documentation (same 
> for Solr) and export it as configuration
> - The main packaging will use the artifacts provided to put it into TGZ. Also 
> Release manager can build documentation using the above gradlew calls.



--
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] [Resolved] (LUCENE-9577) Move HTML Documentation to a separate subproject

2020-10-09 Thread Uwe Schindler (Jira)



 [ 
https://issues.apache.org/jira/browse/LUCENE-9577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved LUCENE-9577.
---
Resolution: Fixed

I merged the PR and adapted the Jenkins jobs to call the new tasks.
As the documentation build folder changed, I also adapted the Jenkins Javadoc 
output folder for archiving.

> Move HTML Documentation to a separate subproject
> 
>
> Key: LUCENE-9577
> URL: https://issues.apache.org/jira/browse/LUCENE-9577
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Currently Lucene/Solr have some subdirectory "site" containing some fragments 
> for CHANGES.txt formatting and the Markdown to produce the site. The global 
> documentation for both Lucene and Solr should be built with its own 
> subproject {{:lucene:documentation}} and {{:solr:documentation}}.
> I will provide a PR that does the following:
> - Move Changes.html formatting scripts to gradle subfolder, so they are 
> correctly shared between Lucene and Gradle and allows to split project 
> (currently they live in Lucene only)
> - Move the site contents with correct names a {{src/assets}}, 
> {{src/markdown}} into the new documentation projects
> - Make packaging of documentation in the projects build.gradle. 
> {{:lucene:documentation:assemble}} should assemble the documentation (same 
> for Solr) and export it as configuration
> - The main packaging will use the artifacts provided to put it into TGZ. Also 
> Release manager can build documentation using the above gradlew calls.



--
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-14470) Add streaming expressions to /export handler

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210921#comment-17210921
 ] 

ASF subversion and git services commented on SOLR-14470:


Commit 5fec41e490430240bd2d0d9e54b5c857e82a9bf4 in lucene-solr's branch 
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5fec41e ]

SOLR-14470: Fix test failures by reducing the randomness of test data.


> Add streaming expressions to /export handler
> 
>
> Key: SOLR-14470
> URL: https://issues.apache.org/jira/browse/SOLR-14470
> Project: Solr
>  Issue Type: Improvement
>  Components: Export Writer, streaming expressions
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Many streaming scenarios would greatly benefit from the ability to perform 
> partial rollups (or other transformations) as early as possible, in order to 
> minimize the amount of data that has to be sent from shards to the 
> aggregating node.
> This can be implemented as a subset of streaming expressions that process the 
> data directly inside each local {{ExportHandler}} and outputs only the 
> records from the resulting stream. 
> Conceptually it would be similar to the way Hadoop {{Combiner}} works. As is 
> the case with {{Combiner}}, because the input data is processed in batches 
> there would be no guarantee that only 1 record per unique sort values would 
> be emitted - in fact, in most cases multiple partial aggregations would be 
> emitted. Still, in many scenarios this would allow reducing the amount of 
> data to be sent by several orders of magnitude.



--
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-14729) Investigate and harden TestExportWriter.testExpr failures

2020-10-09 Thread Munendra S N (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210922#comment-17210922
 ] 

Munendra S N commented on SOLR-14729:
-

Fix for test failures(SOLR-14470) was not backported to 8x. I have backported 
it now which should fix the failure(verified with beasting). Closing this now, 
will reopen if it fails again

> Investigate and harden TestExportWriter.testExpr failures
> -
>
> Key: SOLR-14729
> URL: https://issues.apache.org/jira/browse/SOLR-14729
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>Priority: Major
>
> TestExportWriter.testExpr is failing way too much (6.4% of the time). This 
> ticket will fix the problem.



--
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] [Resolved] (SOLR-14729) Investigate and harden TestExportWriter.testExpr failures

2020-10-09 Thread Munendra S N (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N resolved SOLR-14729.
-
Resolution: Fixed

> Investigate and harden TestExportWriter.testExpr failures
> -
>
> Key: SOLR-14729
> URL: https://issues.apache.org/jira/browse/SOLR-14729
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>Priority: Major
>
> TestExportWriter.testExpr is failing way too much (6.4% of the time). This 
> ticket will fix the problem.



--
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] rmuir commented on pull request #1961: LUCENE-9567: JPOSSFF loads built-in stop tags by default

2020-10-09 Thread GitBox



rmuir commented on pull request #1961:
URL: https://github.com/apache/lucene-solr/pull/1961#issuecomment-705944672


   +1



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] muse-dev[bot] commented on a change in pull request #1930: LUCENE-9322: add VectorValues to new Lucene90 codec

2020-10-09 Thread GitBox



muse-dev[bot] commented on a change in pull request #1930:
URL: https://github.com/apache/lucene-solr/pull/1930#discussion_r501886824



##
File path: lucene/core/src/java/org/apache/lucene/index/IndexingChain.java
##
@@ -562,6 +614,12 @@ private int processField(int docID, IndexableField field, 
long fieldGen, int fie
   }
   indexPoint(docID, fp, field);
 }
+if (fieldType.vectorDimension() != 0) {
+  if (fp == null) {
+fp = getOrAddField(fieldName, fieldType, false);
+  }
+  indexVector(docID, fp, field);

Review comment:
   *NULL_DEREFERENCE:*  object `fp` last assigned on line 619 could be null 
and is dereferenced by call to `indexVector(...)` at line 621.





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] sigram closed pull request #1951: SOLR-14691: Reduce object creation by using MapWriter / IteratorWriter.

2020-10-09 Thread GitBox



sigram closed pull request #1951:
URL: https://github.com/apache/lucene-solr/pull/1951


   



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] uschindler edited a comment on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



uschindler edited a comment on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-705832388







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] uschindler commented on pull request #1905: LUCENE-9488 Release with Gradle Part 2

2020-10-09 Thread GitBox



uschindler commented on pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#issuecomment-705717342







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] dweiss commented on a change in pull request #1950: LUCENE-9564: add spotless and gjf.

2020-10-09 Thread GitBox



dweiss commented on a change in pull request #1950:
URL: https://github.com/apache/lucene-solr/pull/1950#discussion_r501473380



##
File path: gradle/validation/spotless.gradle
##
@@ -0,0 +1,31 @@
+
+def resources = scriptResources(buildscript)
+ 
+allprojects { prj ->
+  plugins.withType(JavaPlugin) {
+prj.apply plugin: 'com.diffplug.spotless'
+
+spotless {
+  java {
+licenseHeaderFile file("${resources}/asl-header.txt"), '^(\\s*package)'
+lineEndings 'UNIX'
+endWithNewline()
+googleJavaFormat('1.9')
+
+// Known problematic files.
+targetExclude "**/HTMLStripCharFilter.java", 
"**/UAX29URLEmailTokenizerImpl.java", 
+   "**/PatternParser.java", "**/BuildNavDataFiles.java", 
"**/CheckLinksAndAnchors.java",
+   "**/TestSubQueryTransformer.java"

Review comment:
   I was thinking the other way around, actually always apply formatting 
after they run so that you get the same code in the output after regenerating 
these source files. This should be idempotent and have clean formatting too.  
   
   I excluded these particular files because they break the formatter... Some 
of them have no package and others cause stack overflows - 
https://github.com/google/google-java-format/issues/528

##
File path: gradle/validation/spotless.gradle
##
@@ -0,0 +1,31 @@
+
+def resources = scriptResources(buildscript)
+ 
+allprojects { prj ->
+  plugins.withType(JavaPlugin) {
+prj.apply plugin: 'com.diffplug.spotless'
+
+spotless {
+  java {
+licenseHeaderFile file("${resources}/asl-header.txt"), '^(\\s*package)'
+lineEndings 'UNIX'
+endWithNewline()
+googleJavaFormat('1.9')
+
+// Known problematic files.
+targetExclude "**/HTMLStripCharFilter.java", 
"**/UAX29URLEmailTokenizerImpl.java", 
+   "**/PatternParser.java", "**/BuildNavDataFiles.java", 
"**/CheckLinksAndAnchors.java",
+   "**/TestSubQueryTransformer.java"

Review comment:
   Ok, fair enough. I also suggested elsewhere that we might want to just 
move those generated files into a different sourceset so that it's clear they 
are generated and they can be wiped easier upon regeneration. Or is there value 
in keeping them together, do you think?

##
File path: gradle/validation/spotless.gradle
##
@@ -0,0 +1,31 @@
+
+def resources = scriptResources(buildscript)
+ 
+allprojects { prj ->
+  plugins.withType(JavaPlugin) {
+prj.apply plugin: 'com.diffplug.spotless'
+
+spotless {
+  java {
+licenseHeaderFile file("${resources}/asl-header.txt"), '^(\\s*package)'
+lineEndings 'UNIX'
+endWithNewline()
+googleJavaFormat('1.9')
+
+// Known problematic files.
+targetExclude "**/HTMLStripCharFilter.java", 
"**/UAX29URLEmailTokenizerImpl.java", 
+   "**/PatternParser.java", "**/BuildNavDataFiles.java", 
"**/CheckLinksAndAnchors.java",
+   "**/TestSubQueryTransformer.java"

Review comment:
   Ok, I'll see what can be done when I get there.





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] dweiss commented on pull request #1905: LUCENE-9488 Release with Gradle Part 2

2020-10-09 Thread GitBox



dweiss commented on pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#issuecomment-705794061


   This isn't so easy as the current gradle build can't be separated into 
Lucene and Solr-only parts (as it was the case with ant). We could distribute 
everything (Solr and Lucene sources) or wait until builds are separated (which 
I showed is not that much of a big deal).



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] dweiss commented on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



dweiss commented on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-705996331


   >
   > Maybe I'm blind, but I scanned that page and do not see the "release docs" 
link - tried Ctrl-F too
   >
   >
   The link is on Lucene's page, here:
   https://lucene.apache.org/core/
   



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] msokolov commented on a change in pull request #1930: LUCENE-9322: add VectorValues to new Lucene90 codec

2020-10-09 Thread GitBox



msokolov commented on a change in pull request #1930:
URL: https://github.com/apache/lucene-solr/pull/1930#discussion_r501828351



##
File path: lucene/core/src/java/org/apache/lucene/index/VectorValues.java
##
@@ -0,0 +1,264 @@
+/*
+ * 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.index;
+
+import java.io.IOException;
+
+import org.apache.lucene.search.DocIdSetIterator;
+import org.apache.lucene.search.TopDocs;
+import org.apache.lucene.util.BytesRef;
+
+/**
+ * Access to per-document vector value.
+ */
+public abstract class VectorValues extends DocIdSetIterator {
+
+  /** The maximum length of a vector */
+  public static int MAX_DIMENSIONS = 1024;
+
+  /** Sole constructor */
+  protected VectorValues() {}
+
+  /**
+   * Return the dimension of the vectors
+   */
+  public abstract int dimension();
+
+  /**
+   * TODO: should we use cost() for this? We rely on its always being exactly 
the number
+   * of documents having a value for this field, which is not guaranteed by 
the cost() contract,
+   * but in all the implementations so far they are the same.
+   * @return the number of vectors returned by this iterator
+   */
+  public abstract int size();
+
+  /**
+   * Return the score function used to compare these vectors
+   */
+  public abstract ScoreFunction scoreFunction();
+
+  /**
+   * Return the vector value for the current document ID.
+   * It is illegal to call this method after the iterator failed to advance.
+   * @return the vector value
+   */
+  public abstract float[] vectorValue() throws IOException;
+
+  /**
+   * Return the binary encoded vector value for the current document ID.
+   * It is illegal to call this method after the iterator failed to advance.
+   * @return the binary value
+   */
+  public BytesRef binaryValue() throws IOException {
+throw new UnsupportedOperationException();
+  }
+
+  /**
+   * Return a random access interface over this iterator's vectors.
+   */
+  public abstract RandomAccess randomAccess();
+
+  /**
+   * Provides random access to vectors by dense ordinal
+   */
+  public interface RandomAccess {
+
+/**
+ * Return the vector value as a floating point array.
+ * @param targetOrd a valid ordinal, ≥ 0 and < {@link #size()}.
+ */
+float[] vectorValue(int targetOrd) throws IOException;
+
+/**
+ * Return the vector value as a byte array; these are the bytes 
corresponding to the float array
+ * encoded using little-endian byte order.
+ * @param targetOrd a valid ordinal, ≥ 0 and < {@link #size()}.
+ */
+BytesRef binaryValue(int targetOrd) throws IOException;
+
+/**
+ * Return the k nearest neighbor documents as determined by comparison of 
their vector values
+ * for this field, to the given vector, by the field's score function. If 
the score function is
+ * reversed, lower values indicate nearer vectors, otherwise higher scores 
indicate nearer
+ * vectors. Unlike relevance scores, vector scores may be negative.
+ * @param target the vector-valued query
+ * @param k  the number of docs to return
+ * @param fanout control the accuracy/speed tradeoff - larger values give 
better recall at higher cost
+ * @return the k nearest neighbor documents, along with their 
(scoreFunction-specific) scores.
+ */
+TopDocs search(float[] target, int k, int fanout) throws IOException;
+  }
+
+  /**
+   * Score function. This is used during indexing and searching of the vectors 
to determine the nearest neighbors.
+   * Score values may be negative. By default high scores indicate nearer 
documents, unless the function is reversed.
+   */
+  public enum ScoreFunction {
+/** No distance function is used. Note: {@link 
VectorValues.RandomAccess#search(float[], int, int)}

Review comment:
   OK I opened LUCENE-9573. I have to admit I don't fully understand the 
timing constraints/dependencies here. Maybe you could comment on that issue?  
Re: the ids I opted to move to using the enum ordinal as you suggested later. I 
can't see how that restricts us in any meaningful way. Perhaps we add a 
back-compat test to verify that the enum ordinals don't change




--

[GitHub] [lucene-solr] noblepaul commented on pull request #1953: SOLR-14917: Move DOMUtil and PropertiesUtil to SolrJ

2020-10-09 Thread GitBox



noblepaul commented on pull request #1953:
URL: https://github.com/apache/lucene-solr/pull/1953#issuecomment-705486732


   I have no objection to moving them. 
   
   But is there any particular reason why you wish to move them? 



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] dweiss commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



dweiss commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-706022783







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] (SOLR-14708) Backward-Compatible Replication

2020-10-09 Thread Cassandra Targett (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210966#comment-17210966
 ] 

Cassandra Targett commented on SOLR-14708:
--

Thanks Tomas, that's very helpful. I'll work through some instructions for the 
types of changes people should make in solrconfig (and maybe other places) and 
note they should not make them until all nodes are on 8.7. I think it will 
unfortunately require re-introducing the terms but only to be clear on how to 
excise them.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
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] uschindler edited a comment on pull request #1905: LUCENE-9488 Release with Gradle Part 2

2020-10-09 Thread GitBox



uschindler edited a comment on pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#issuecomment-705717342







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] gus-asf commented on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



gus-asf commented on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-705761838







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] noblepaul merged pull request #1932: Reuse crypto keys in reference impl

2020-10-09 Thread GitBox



noblepaul merged pull request #1932:
URL: https://github.com/apache/lucene-solr/pull/1932


   



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] gus-asf commented on a change in pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



gus-asf commented on a change in pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#discussion_r502142268



##
File path: 
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/DropIfFlaggedFilter.java
##
@@ -0,0 +1,90 @@
+/*
+ * 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.analysis.miscellaneous;
+
+import java.io.IOException;
+import java.util.UUID;
+
+import org.apache.lucene.analysis.TokenFilter;
+import org.apache.lucene.analysis.TokenStream;
+import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;
+import org.apache.lucene.analysis.tokenattributes.FlagsAttribute;
+
+/**
+ * Allows Tokens with a given combination of flags to be dropped.
+ *
+ * @see DropIfFlaggedFilterFactory
+ */
+public class DropIfFlaggedFilter extends TokenFilter {
+
+  private int dropFlags;
+
+  private CharTermAttribute attribute = getAttribute(CharTermAttribute.class);
+  private boolean firstToken = true;
+
+  /**
+   * Construct a token stream filtering the given input.
+   *
+   * @param input the source stream
+   * @param dropFlags a combination of flags that indicates that the token 
should be dropped.
+   */
+  @SuppressWarnings("WeakerAccess")
+  protected DropIfFlaggedFilter(TokenStream input, int dropFlags) {
+super(input);
+this.dropFlags = dropFlags;
+  }
+
+  @Override
+  public final boolean incrementToken() throws IOException {
+boolean result;
+boolean dropToken;
+do {
+  result = input.incrementToken();
+  dropToken = (getAttribute(FlagsAttribute.class).getFlags() & dropFlags) 
== dropFlags;

Review comment:
   I guess this has been working because org.apache.lucene.analysis.Token 
happens to have this attribute already, but of course that's not guaranteed to 
be the impl one gets.
   
   The final field... I've seen this done in a number of places including doc 
examples but I don't recall (and haven't been able to locate documentation as 
to) why it's important. Is there anything to it beyond saving an Class.cast() 
and a Map.get() call? It is a very hot area of the code so maybe something that 
small does matter here... Also I wonder if anything like the following has been 
considered so that users don't have to explicitly add attributes:
   
   ```
 public final  T getAttributeSafe(Class attClass) {
   return attClass.cast(attributes.computeIfAbsent(attClass, 
this::addAttribute));
 }
   ```
   That doesn't quite work with the current generics and obviously not for this 
ticket but is that an already discarded idea?





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] msokolov commented on pull request #1961: LUCENE-9567: JPOSSFF loads built-in stop tags by default

2020-10-09 Thread GitBox



msokolov commented on pull request #1961:
URL: https://github.com/apache/lucene-solr/pull/1961#issuecomment-705849891


   looks good - I will merge soon if nobody objects



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] uschindler merged pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



uschindler merged pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967


   



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] uschindler commented on pull request #1967: LUCENE-9577: Move Lucene/Solr Documentation assembly to subproject

2020-10-09 Thread GitBox



uschindler commented on pull request #1967:
URL: https://github.com/apache/lucene-solr/pull/1967#issuecomment-705884519







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] rmuir commented on a change in pull request #1950: LUCENE-9564: add spotless and gjf.

2020-10-09 Thread GitBox



rmuir commented on a change in pull request #1950:
URL: https://github.com/apache/lucene-solr/pull/1950#discussion_r501488766



##
File path: gradle/validation/spotless.gradle
##
@@ -0,0 +1,31 @@
+
+def resources = scriptResources(buildscript)
+ 
+allprojects { prj ->
+  plugins.withType(JavaPlugin) {
+prj.apply plugin: 'com.diffplug.spotless'
+
+spotless {
+  java {
+licenseHeaderFile file("${resources}/asl-header.txt"), '^(\\s*package)'
+lineEndings 'UNIX'
+endWithNewline()
+googleJavaFormat('1.9')
+
+// Known problematic files.
+targetExclude "**/HTMLStripCharFilter.java", 
"**/UAX29URLEmailTokenizerImpl.java", 
+   "**/PatternParser.java", "**/BuildNavDataFiles.java", 
"**/CheckLinksAndAnchors.java",
+   "**/TestSubQueryTransformer.java"

Review comment:
   sorry, wrong button click. I still think this might be the wrong 
tradeoff. while it might make the gradle look simpler, it makes it awful for 
the one trying to work with the actual regeneration, it is really hard to keep 
in working correctly.
   

##
File path: gradle/validation/spotless.gradle
##
@@ -0,0 +1,31 @@
+
+def resources = scriptResources(buildscript)
+ 
+allprojects { prj ->
+  plugins.withType(JavaPlugin) {
+prj.apply plugin: 'com.diffplug.spotless'
+
+spotless {
+  java {
+licenseHeaderFile file("${resources}/asl-header.txt"), '^(\\s*package)'
+lineEndings 'UNIX'
+endWithNewline()
+googleJavaFormat('1.9')
+
+// Known problematic files.
+targetExclude "**/HTMLStripCharFilter.java", 
"**/UAX29URLEmailTokenizerImpl.java", 
+   "**/PatternParser.java", "**/BuildNavDataFiles.java", 
"**/CheckLinksAndAnchors.java",
+   "**/TestSubQueryTransformer.java"

Review comment:
   its worth thinking about yeah. if there was a consolidated list of them 
maybe it would make other tasks more intuitive: e.g. remove the crazy 
"Generated" matching that's in RAT and simply exclude them from license 
analysis too.





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] rmuir commented on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



rmuir commented on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-705724494







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] noblepaul merged pull request #1586: SOLR-14576 : Do not use SolrCore as keys in a WeakHashMap

2020-10-09 Thread GitBox



noblepaul merged pull request #1586:
URL: https://github.com/apache/lucene-solr/pull/1586


   



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] muse-dev[bot] commented on a change in pull request #1963: SOLR-14827: Refactor schema loading to not use XPath

2020-10-09 Thread GitBox



muse-dev[bot] commented on a change in pull request #1963:
URL: https://github.com/apache/lucene-solr/pull/1963#discussion_r501702700



##
File path: solr/core/src/java/org/apache/solr/schema/IndexSchema.java
##
@@ -474,23 +481,28 @@ protected Analyzer getWrappedAnalyzer(String fieldName) {
 }
   }
 
-  protected void readSchema(InputSource is) {
+  protected void readSchema(ConfigSetService.ConfigResource is) {
 assert null != is : "schema InputSource should never be null";
 try {
-  // pass the config resource loader to avoid building an empty one for no 
reason:
-  // in the current case though, the stream is valid so we wont load the 
resource by name
-  XmlConfigFile schemaConf = new XmlConfigFile(loader, SCHEMA, is, 
SLASH+SCHEMA+SLASH, substitutableProperties);
-  Document document = schemaConf.getDocument();
-  final XPath xpath = schemaConf.getXPath();
-  String expression = stepsToPath(SCHEMA, AT + NAME);
-  Node nd = (Node) xpath.evaluate(expression, document, 
XPathConstants.NODE);
+  rootNode = is.getParsed();
+  if(rootNode == null) {
+// pass the config resource loader to avoid building an empty one for 
no reason:
+// in the current case though, the stream is valid so we wont load the 
resource by name
+XmlConfigFile schemaConf = new XmlConfigFile(loader, SCHEMA, 
is.getSource(), SLASH+SCHEMA+SLASH, null);
+//  Document document = schemaConf.getDocument();
+//  final XPath xpath = schemaConf.getXPath();
+//  String expression = stepsToPath(SCHEMA, AT + NAME);
+//  Node nd = (Node) xpath.evaluate(expression, document, 
XPathConstants.NODE);
+rootNode = new DataConfigNode(new 
DOMConfigNode(schemaConf.getDocument().getDocumentElement())) ;

Review comment:
   *NULL_DEREFERENCE:*  object returned by `getDocument(schemaConf)` could 
be null and is dereferenced at line 496.

##
File path: solr/core/src/java/org/apache/solr/schema/IndexSchema.java
##
@@ -608,7 +629,7 @@ protected void readSchema(InputSource is) {
   // expression = "/schema/copyField";
 
   dynamicCopyFields = new DynamicCopy[] {};

Review comment:
   *THREAD_SAFETY_VIOLATION:*  Unprotected write. Non-private method 
`IndexSchema.readSchema(...)` writes to field `this.dynamicCopyFields` outside 
of synchronization.
Reporting because another access to the same memory occurs on a background 
thread, although this access may not.

##
File path: 
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
##
@@ -174,8 +175,8 @@ public ManagedIndexSchema create(String resourceName, 
SolrConfig config) {
 }
 InputSource inputSource = new InputSource(schemaInputStream);
 
inputSource.setSystemId(SystemIdResolver.createSystemIdFromResourceName(loadedResource));

Review comment:
   *THREAD_SAFETY_VIOLATION:*  Read/Write race. Non-private method 
`ManagedIndexSchemaFactory.create(...)` reads without synchronization from 
`this.loadedResource`. Potentially races with write in method 
`ManagedIndexSchemaFactory.create(...)`.
Reporting because this access may occur on a background thread.

##
File path: 
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
##
@@ -174,8 +175,8 @@ public ManagedIndexSchema create(String resourceName, 
SolrConfig config) {
 }
 InputSource inputSource = new InputSource(schemaInputStream);
 
inputSource.setSystemId(SystemIdResolver.createSystemIdFromResourceName(loadedResource));
-schema = new ManagedIndexSchema(config, loadedResource, inputSource, 
isMutable,
-managedSchemaResourceName, 
schemaZkVersion, getSchemaUpdateLock());
+schema = new ManagedIndexSchema(config, loadedResource, () -> inputSource, 
isMutable,
+managedSchemaResourceName, schemaZkVersion, getSchemaUpdateLock());
 if (shouldUpgrade) {

Review comment:
   *THREAD_SAFETY_VIOLATION:*  Read/Write race. Non-private method 
`ManagedIndexSchemaFactory.create(...)` reads without synchronization from 
`this.shouldUpgrade`. Potentially races with write in method 
`ManagedIndexSchemaFactory.create(...)`.
Reporting because this access may occur on a background thread.

##
File path: 
solr/core/src/java/org/apache/solr/schema/ManagedIndexSchemaFactory.java
##
@@ -174,8 +175,8 @@ public ManagedIndexSchema create(String resourceName, 
SolrConfig config) {
 }
 InputSource inputSource = new InputSource(schemaInputStream);
 
inputSource.setSystemId(SystemIdResolver.createSystemIdFromResourceName(loadedResource));
-schema = new ManagedIndexSchema(config, loadedResource, inputSource, 
isMutable,
-managedSchemaResourceName, 
schemaZkVersion, getSchemaUpdateLock());
+schema = new ManagedIndexSchema(config, loadedResource, () -> inputSource, 
isMutable,
+managedSchemaResourceName, s

[GitHub] [lucene-solr] uschindler commented on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



uschindler commented on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-705735154







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] sigram commented on pull request #1951: SOLR-14691: Reduce object creation by using MapWriter / IteratorWriter.

2020-10-09 Thread GitBox



sigram commented on pull request #1951:
URL: https://github.com/apache/lucene-solr/pull/1951#issuecomment-705484706


   Merged - 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.

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] madrob commented on pull request #1905: LUCENE-9488 Release with Gradle Part 2

2020-10-09 Thread GitBox



madrob commented on pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#issuecomment-705772790







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] uschindler commented on a change in pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



uschindler commented on a change in pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#discussion_r501917428



##
File path: 
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/DropIfFlaggedFilter.java
##
@@ -0,0 +1,90 @@
+/*
+ * 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.analysis.miscellaneous;
+
+import java.io.IOException;
+import java.util.UUID;
+
+import org.apache.lucene.analysis.TokenFilter;
+import org.apache.lucene.analysis.TokenStream;
+import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;
+import org.apache.lucene.analysis.tokenattributes.FlagsAttribute;
+
+/**
+ * Allows Tokens with a given combination of flags to be dropped.
+ *
+ * @see DropIfFlaggedFilterFactory
+ */
+public class DropIfFlaggedFilter extends TokenFilter {
+
+  private int dropFlags;
+
+  private CharTermAttribute attribute = getAttribute(CharTermAttribute.class);
+  private boolean firstToken = true;
+
+  /**
+   * Construct a token stream filtering the given input.
+   *
+   * @param input the source stream
+   * @param dropFlags a combination of flags that indicates that the token 
should be dropped.
+   */
+  @SuppressWarnings("WeakerAccess")
+  protected DropIfFlaggedFilter(TokenStream input, int dropFlags) {
+super(input);
+this.dropFlags = dropFlags;
+  }
+
+  @Override
+  public final boolean incrementToken() throws IOException {
+boolean result;
+boolean dropToken;
+do {
+  result = input.incrementToken();
+  dropToken = (getAttribute(FlagsAttribute.class).getFlags() & dropFlags) 
== dropFlags;

Review comment:
   you have to move this to final fiel and use FlagsAttribute flagsAttr = 
addAttribute(FlagsAttribute.class)

##
File path: 
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/DropIfFlaggedFilter.java
##
@@ -0,0 +1,90 @@
+/*
+ * 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.analysis.miscellaneous;
+
+import java.io.IOException;
+import java.util.UUID;
+
+import org.apache.lucene.analysis.TokenFilter;
+import org.apache.lucene.analysis.TokenStream;
+import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;
+import org.apache.lucene.analysis.tokenattributes.FlagsAttribute;
+
+/**
+ * Allows Tokens with a given combination of flags to be dropped.
+ *
+ * @see DropIfFlaggedFilterFactory
+ */
+public class DropIfFlaggedFilter extends TokenFilter {
+
+  private int dropFlags;
+
+  private CharTermAttribute attribute = getAttribute(CharTermAttribute.class);
+  private boolean firstToken = true;
+
+  /**
+   * Construct a token stream filtering the given input.
+   *
+   * @param input the source stream
+   * @param dropFlags a combination of flags that indicates that the token 
should be dropped.
+   */
+  @SuppressWarnings("WeakerAccess")
+  protected DropIfFlaggedFilter(TokenStream input, int dropFlags) {
+super(input);
+this.dropFlags = dropFlags;
+  }
+
+  @Override
+  public final boolean incrementToken() throws IOException {
+boolean result;
+boolean dropToken;
+do {
+  result = input.incrementToken();
+  dropToken = (getAttribute(FlagsAttribute.class).getFlags() & dropFlags) 
== dropFlags;

Review comment:
   you have to move this to final field and use `final FlagsAttribute 
flagsAttr = addAttribute(FlagsAttribute.class);` as instance member.

##
File pat

[GitHub] [lucene-solr] msokolov commented on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



msokolov commented on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-705943997


   > > Would be nice if lucene had docs that included a table of contents or 
navigation by topic so that one didn't have to wade through a single (or a 
small number of) giant javadoc pages with many sections unrelated to whatever 
one is actually trying to understand at the moment.
   > 
   > As far as the docs go, I do think for this stuff, it is pretty prominent: 
if you go to lucene.apache.org and click "release docs" it takes you here: 
https://lucene.apache.org/core/8_6_3/index.html
   > 
   > Right at the top under "Getting Started" are two decent links that help 
with writing analysis stuff:
   > 
   > 1. Analysis Overview: 
https://lucene.apache.org/core/8_6_3/core/org/apache/lucene/analysis/package-summary.html#package.description
   >   As far as the docs go, I do think for this stuff, it is pretty 
prominent: if you go to lucene.apache.org and click "release docs" it takes you 
here
   
   Maybe I'm blind, but I scanned that page and do not see the "release docs" 
link - tried Ctrl-F too
   
   



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] dsmiley commented on pull request #1953: SOLR-14917: Move DOMUtil and PropertiesUtil to SolrJ

2020-10-09 Thread GitBox



dsmiley commented on pull request #1953:
URL: https://github.com/apache/lucene-solr/pull/1953#issuecomment-705546872


   I leave JIRA for context/motivation and PRs for the details, and so my PRs 
are often lacking anything other than a JIRA link.  This issue, SOLR-14917 is a 
child task of https://issues.apache.org/jira/browse/SOLR-14915 which removes 
the Prometheus Exporter's dependency on Solr-core.



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] madrob merged pull request #1905: LUCENE-9488 Release with Gradle Part 2

2020-10-09 Thread GitBox



madrob merged pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905


   



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] gus-asf edited a comment on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



gus-asf edited a comment on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-705761838







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] msokolov commented on pull request #1930: LUCENE-9322: add VectorValues to new Lucene90 codec

2020-10-09 Thread GitBox



msokolov commented on pull request #1930:
URL: https://github.com/apache/lucene-solr/pull/1930#issuecomment-706185147


   > Agreed that benchmarking is needed. I think we can use 
http://ann-benchmarks.com/ as a guide for some standardized test vectors.
   
   Hmm I tried to get that benchmarking suite to run and it requires some major 
Python-fu. That package relies on docker, scipy, scikit-learn, h5py, 
matplotlib, and these in turn rely on a lot of native libraries, and all the 
versions have to be just right. I didn't have the right versions in my package 
manager's repos, so I had to install from source, and was never able to get the 
right combination, so I finally just gave up on that approach. Maybe someday we 
can use it to compare the performance of this solution with SOA native 
libraries, but not today!
   
   I'll try having a look at the Wikipedia-derived vectors to see if we can at 
least develop our own internal benchmarks in luceneutil.



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] uschindler edited a comment on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



uschindler edited a comment on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-706194402







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-9577) Move HTML Documentation to a separate subproject

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211042#comment-17211042
 ] 

ASF subversion and git services commented on LUCENE-9577:
-

Commit f97208a790ff836ab1abb54d016f1a8f61d48617 in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f97208a ]

LUCENE-9577: fix changed task name


> Move HTML Documentation to a separate subproject
> 
>
> Key: LUCENE-9577
> URL: https://issues.apache.org/jira/browse/LUCENE-9577
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently Lucene/Solr have some subdirectory "site" containing some fragments 
> for CHANGES.txt formatting and the Markdown to produce the site. The global 
> documentation for both Lucene and Solr should be built with its own 
> subproject {{:lucene:documentation}} and {{:solr:documentation}}.
> I will provide a PR that does the following:
> - Move Changes.html formatting scripts to gradle subfolder, so they are 
> correctly shared between Lucene and Gradle and allows to split project 
> (currently they live in Lucene only)
> - Move the site contents with correct names a {{src/assets}}, 
> {{src/markdown}} into the new documentation projects
> - Make packaging of documentation in the projects build.gradle. 
> {{:lucene:documentation:assemble}} should assemble the documentation (same 
> for Solr) and export it as configuration
> - The main packaging will use the artifacts provided to put it into TGZ. Also 
> Release manager can build documentation using the above gradlew calls.



--
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-14616) Remove CDCR from 9.0

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211053#comment-17211053
 ] 

ASF subversion and git services commented on SOLR-14616:


Commit fc018bf572d645eca1701bf7085c25ebb5b93cd5 in lucene-solr's branch 
refs/heads/reference_impl_dev from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fc018bf ]

SOLR-14616: Remove CDCR


> Remove CDCR from 9.0
> 
>
> Key: SOLR-14616
> URL: https://issues.apache.org/jira/browse/SOLR-14616
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: master (9.0)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (9.0)
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This was deprecated in SOLR-14022 and should be removed in 9.0.



--
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-9577) Move HTML Documentation to a separate subproject

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211056#comment-17211056
 ] 

ASF subversion and git services commented on LUCENE-9577:
-

Commit 6acb7b4293b057765703a393baad330f431e7f50 in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6acb7b4 ]

LUCENE-9577: move the checkBrokenLinks task to the documentation subprojects


> Move HTML Documentation to a separate subproject
> 
>
> Key: LUCENE-9577
> URL: https://issues.apache.org/jira/browse/LUCENE-9577
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently Lucene/Solr have some subdirectory "site" containing some fragments 
> for CHANGES.txt formatting and the Markdown to produce the site. The global 
> documentation for both Lucene and Solr should be built with its own 
> subproject {{:lucene:documentation}} and {{:solr:documentation}}.
> I will provide a PR that does the following:
> - Move Changes.html formatting scripts to gradle subfolder, so they are 
> correctly shared between Lucene and Gradle and allows to split project 
> (currently they live in Lucene only)
> - Move the site contents with correct names a {{src/assets}}, 
> {{src/markdown}} into the new documentation projects
> - Make packaging of documentation in the projects build.gradle. 
> {{:lucene:documentation:assemble}} should assemble the documentation (same 
> for Solr) and export it as configuration
> - The main packaging will use the artifacts provided to put it into TGZ. Also 
> Release manager can build documentation using the above gradlew calls.



--
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] msokolov merged pull request #1961: LUCENE-9567: JPOSSFF loads built-in stop tags by default

2020-10-09 Thread GitBox



msokolov merged pull request #1961:
URL: https://github.com/apache/lucene-solr/pull/1961


   



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-9567) JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by default

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211064#comment-17211064
 ] 

ASF subversion and git services commented on LUCENE-9567:
-

Commit 4e0aa0d23bbd577c4c96bb56b52d3bb558050c11 in lucene-solr's branch 
refs/heads/master from msfroh
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4e0aa0d ]

LUCENE-9567: JPOSSFF loads built-in stop tags by default (#1961)

load stoptags.txt from analysis-kuromoji when no tags argument is specified

> JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by 
> default
> ---
>
> Key: LUCENE-9567
> URL: https://issues.apache.org/jira/browse/LUCENE-9567
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 8.6
>Reporter: Michael Froh
>Priority: Minor
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If JapanesePartOfSpeechStopFilterFactory is given empty args, it does 
> nothing. It doesn't load any stop tags, and just passes along the TokenStream 
> passed to create().
> As a default behavior, this is trappy, since a user may add the filter 
> without explicitly adding any arguments and assume that it would load a 
> "default" stop set. Or they may assume that if an explicit argument is 
> required then an exception will be thrown. Regardless, "doing nothing" is 
> almost certainly not what the user intended.
> I'm going to attach a patch to load the default stop tags (using 
> {{JapaneseAnalyzer.getDefaultStopTags()}}) if no args are specified, which 
> probably makes sense in 9.0 (as it's consistent with e.g. 
> KoreanPartOfSpeechStopFilterFactory). If we want to apply a fix to 8.x, maybe 
> throw an exception to let the use know that the FilterFactory probably isn't 
> doing what they think it's doing?



--
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] msokolov commented on pull request #1968: LUCENE-9562: Unify 'analysis' package with produced artifact names (-analyzers- to -analysis-)

2020-10-09 Thread GitBox



msokolov commented on pull request #1968:
URL: https://github.com/apache/lucene-solr/pull/1968#issuecomment-706231430


   +1 - this would be for 9.0 only, I assume?



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-9567) JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by default

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211065#comment-17211065
 ] 

ASF subversion and git services commented on LUCENE-9567:
-

Commit 4e0aa0d23bbd577c4c96bb56b52d3bb558050c11 in lucene-solr's branch 
refs/heads/master from msfroh
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4e0aa0d ]

LUCENE-9567: JPOSSFF loads built-in stop tags by default (#1961)

load stoptags.txt from analysis-kuromoji when no tags argument is specified

> JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by 
> default
> ---
>
> Key: LUCENE-9567
> URL: https://issues.apache.org/jira/browse/LUCENE-9567
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 8.6
>Reporter: Michael Froh
>Priority: Minor
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If JapanesePartOfSpeechStopFilterFactory is given empty args, it does 
> nothing. It doesn't load any stop tags, and just passes along the TokenStream 
> passed to create().
> As a default behavior, this is trappy, since a user may add the filter 
> without explicitly adding any arguments and assume that it would load a 
> "default" stop set. Or they may assume that if an explicit argument is 
> required then an exception will be thrown. Regardless, "doing nothing" is 
> almost certainly not what the user intended.
> I'm going to attach a patch to load the default stop tags (using 
> {{JapaneseAnalyzer.getDefaultStopTags()}}) if no args are specified, which 
> probably makes sense in 9.0 (as it's consistent with e.g. 
> KoreanPartOfSpeechStopFilterFactory). If we want to apply a fix to 8.x, maybe 
> throw an exception to let the use know that the FilterFactory probably isn't 
> doing what they think it's doing?



--
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-9567) JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by default

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211067#comment-17211067
 ] 

ASF subversion and git services commented on LUCENE-9567:
-

Commit 4e0aa0d23bbd577c4c96bb56b52d3bb558050c11 in lucene-solr's branch 
refs/heads/master from msfroh
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4e0aa0d ]

LUCENE-9567: JPOSSFF loads built-in stop tags by default (#1961)

load stoptags.txt from analysis-kuromoji when no tags argument is specified

> JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by 
> default
> ---
>
> Key: LUCENE-9567
> URL: https://issues.apache.org/jira/browse/LUCENE-9567
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 8.6
>Reporter: Michael Froh
>Priority: Minor
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If JapanesePartOfSpeechStopFilterFactory is given empty args, it does 
> nothing. It doesn't load any stop tags, and just passes along the TokenStream 
> passed to create().
> As a default behavior, this is trappy, since a user may add the filter 
> without explicitly adding any arguments and assume that it would load a 
> "default" stop set. Or they may assume that if an explicit argument is 
> required then an exception will be thrown. Regardless, "doing nothing" is 
> almost certainly not what the user intended.
> I'm going to attach a patch to load the default stop tags (using 
> {{JapaneseAnalyzer.getDefaultStopTags()}}) if no args are specified, which 
> probably makes sense in 9.0 (as it's consistent with e.g. 
> KoreanPartOfSpeechStopFilterFactory). If we want to apply a fix to 8.x, maybe 
> throw an exception to let the use know that the FilterFactory probably isn't 
> doing what they think it's doing?



--
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-9567) JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by default

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211068#comment-17211068
 ] 

ASF subversion and git services commented on LUCENE-9567:
-

Commit 4e0aa0d23bbd577c4c96bb56b52d3bb558050c11 in lucene-solr's branch 
refs/heads/master from msfroh
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4e0aa0d ]

LUCENE-9567: JPOSSFF loads built-in stop tags by default (#1961)

load stoptags.txt from analysis-kuromoji when no tags argument is specified

> JapanesePartOfSpeechStopFilterFactory should load built-in stop tags by 
> default
> ---
>
> Key: LUCENE-9567
> URL: https://issues.apache.org/jira/browse/LUCENE-9567
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 8.6
>Reporter: Michael Froh
>Priority: Minor
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If JapanesePartOfSpeechStopFilterFactory is given empty args, it does 
> nothing. It doesn't load any stop tags, and just passes along the TokenStream 
> passed to create().
> As a default behavior, this is trappy, since a user may add the filter 
> without explicitly adding any arguments and assume that it would load a 
> "default" stop set. Or they may assume that if an explicit argument is 
> required then an exception will be thrown. Regardless, "doing nothing" is 
> almost certainly not what the user intended.
> I'm going to attach a patch to load the default stop tags (using 
> {{JapaneseAnalyzer.getDefaultStopTags()}}) if no args are specified, which 
> probably makes sense in 9.0 (as it's consistent with e.g. 
> KoreanPartOfSpeechStopFilterFactory). If we want to apply a fix to 8.x, maybe 
> throw an exception to let the use know that the FilterFactory probably isn't 
> doing what they think it's doing?



--
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] msokolov commented on pull request #1966: LUCENE-9574 Add DropIfFlaggedFilterFactory

2020-10-09 Thread GitBox



msokolov commented on pull request #1966:
URL: https://github.com/apache/lucene-solr/pull/1966#issuecomment-706236565


   > The link is on Lucene's page, here: https://lucene.apache.org/core/
   
   Thanks, @dweiss . The Documentation link is nice and prominent there



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-9568) FuzzyTermEnums sets negative boost for fuzzy search & highlight

2020-10-09 Thread Michael McCandless (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211079#comment-17211079
 ] 

Michael McCandless commented on LUCENE-9568:


Here's the user list discussion leading to this issue: 
[https://markmail.org/thread/2gomdeis3xs7gs5t]

... where [~msoko...@gmail.com] suggested:
{noformat}
I traced this to this block in FuzzyTermsEnum:

    if (ed == 0) { // exact match
      boostAtt.setBoost(1.0F);
    } else {
      final int codePointCount = UnicodeUtil.codePointCount(term);
      int minTermLength = Math.min(codePointCount, termLength);

      float similarity = 1.0f - (float) ed / (float) minTermLength;
      boostAtt.setBoost(similarity);
    }

where in your test ed (edit distance) was 2 and minTermLength 1,
leading to negative boost.

I don't really understand this code at all, but I wonder if it should
divide by maxTermLength instead of minTermLength? {noformat}
I think his proposal makes sense?  That would make {{similarity}} 0 for this 
case, which seems right, since the term is length 1, the candidate is edit 
distance 2 away, and is surely very irrelevant!

> FuzzyTermEnums sets negative boost for fuzzy search & highlight
> ---
>
> Key: LUCENE-9568
> URL: https://issues.apache.org/jira/browse/LUCENE-9568
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 8.5.1
>Reporter: Juraj Jurčo
>Priority: Minor
>  Labels: highlighting, newbie
> Attachments: FindSqlHighlightTest.java
>
>
> *Description*
>  When user indexes a word with an apostrophe and constructs a fuzzy query for 
> highlighter, it throws an exception with set negative boost for a query. 
> *Repro Steps*
>  # Index a text with apostrophe. E.g. doesn't
>  # Parse a fuzzy query e.g.: se~, se~2, se~3
>  # Try to highlight a text with apostrophe
>  # The exception is thrown (for details see attached test test with repro 
> steps)
> *Actual Result*
>  {{java.lang.IllegalArgumentException: boost must be a positive float, got 
> -1.0}}
> *Expected Result*
>  * No exception.
>  * Highlighting marks are inserted into a text.
> *Workaround*
>  - not known.



--
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] [Created] (SOLR-14921) terms filter in json.facet

2020-10-09 Thread gopikannan venugopalsamy (Jira)

gopikannan venugopalsamy created SOLR-14921:
---

 Summary: terms filter in json.facet
 Key: SOLR-14921
 URL: https://issues.apache.org/jira/browse/SOLR-14921
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Reporter: gopikannan venugopalsamy


Hi,
  In normal facet request below can be used to filter the facet terms. I am not 
able to do the same using json.facet. It would be useful in case of multivalued 
field facet and only filtered terms needs to be returned.
 
h3. Limiting Facet with Certain Terms
To limit field facet with certain terms specify them comma separated with 
{{terms}} local parameter. Commas and quotes in terms can be escaped with 
backslash, as in {{\,}}. In this case facet is calculated on a way similar to 
{{facet.method=enum}} , but ignores {{facet.enum.cache.minDf}}. For example:
{{facet.field=\{!terms='alfa,betta,with\,with\',with space'}symbol}}

{{}}
[https://lucene.apache.org/solr/guide/6_6/faceting.html]
 
Just like prefix parameter in json.facet I think we can add terms parameter and 
use it. Something like below.
 
json.facet=\{facets:{type:terms,field:field1,terms:"a,b,c"}}
 
 



--
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] [Updated] (SOLR-14921) terms filter in json.facet

2020-10-09 Thread gopikannan venugopalsamy (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

gopikannan venugopalsamy updated SOLR-14921:

Labels: newbe  (was: )

> terms filter in json.facet
> --
>
> Key: SOLR-14921
> URL: https://issues.apache.org/jira/browse/SOLR-14921
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: gopikannan venugopalsamy
>Priority: Major
>  Labels: newbe
>
> Hi,
>   In normal facet request below can be used to filter the facet terms. I am 
> not able to do the same using json.facet. It would be useful in case of 
> multivalued field facet and only filtered terms needs to be returned.
>  
> h3. Limiting Facet with Certain Terms
> To limit field facet with certain terms specify them comma separated with 
> {{terms}} local parameter. Commas and quotes in terms can be escaped with 
> backslash, as in {{\,}}. In this case facet is calculated on a way similar to 
> {{facet.method=enum}} , but ignores {{facet.enum.cache.minDf}}. For example:
> {{facet.field=\{!terms='alfa,betta,with\,with\',with space'}symbol}}
> {{}}
> [https://lucene.apache.org/solr/guide/6_6/faceting.html]
>  
> Just like prefix parameter in json.facet I think we can add terms parameter 
> and use it. Something like below.
>  
> json.facet=\{facets:{type:terms,field:field1,terms:"a,b,c"}}
>  
>  



--
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] [Updated] (SOLR-14921) terms filter in json.facet

2020-10-09 Thread gopikannan venugopalsamy (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

gopikannan venugopalsamy updated SOLR-14921:

Issue Type: Improvement  (was: Bug)

> terms filter in json.facet
> --
>
> Key: SOLR-14921
> URL: https://issues.apache.org/jira/browse/SOLR-14921
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: gopikannan venugopalsamy
>Priority: Major
>
> Hi,
>   In normal facet request below can be used to filter the facet terms. I am 
> not able to do the same using json.facet. It would be useful in case of 
> multivalued field facet and only filtered terms needs to be returned.
>  
> h3. Limiting Facet with Certain Terms
> To limit field facet with certain terms specify them comma separated with 
> {{terms}} local parameter. Commas and quotes in terms can be escaped with 
> backslash, as in {{\,}}. In this case facet is calculated on a way similar to 
> {{facet.method=enum}} , but ignores {{facet.enum.cache.minDf}}. For example:
> {{facet.field=\{!terms='alfa,betta,with\,with\',with space'}symbol}}
> {{}}
> [https://lucene.apache.org/solr/guide/6_6/faceting.html]
>  
> Just like prefix parameter in json.facet I think we can add terms parameter 
> and use it. Something like below.
>  
> json.facet=\{facets:{type:terms,field:field1,terms:"a,b,c"}}
>  
>  



--
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] [Updated] (SOLR-14921) terms filter in json.facet

2020-10-09 Thread gopikannan venugopalsamy (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

gopikannan venugopalsamy updated SOLR-14921:

Priority: Minor  (was: Major)

> terms filter in json.facet
> --
>
> Key: SOLR-14921
> URL: https://issues.apache.org/jira/browse/SOLR-14921
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: gopikannan venugopalsamy
>Priority: Minor
>
> Hi,
>   In normal facet request below can be used to filter the facet terms. I am 
> not able to do the same using json.facet. It would be useful in case of 
> multivalued field facet and only filtered terms needs to be returned.
>  
> h3. Limiting Facet with Certain Terms
> To limit field facet with certain terms specify them comma separated with 
> {{terms}} local parameter. Commas and quotes in terms can be escaped with 
> backslash, as in {{\,}}. In this case facet is calculated on a way similar to 
> {{facet.method=enum}} , but ignores {{facet.enum.cache.minDf}}. For example:
> {{facet.field=\{!terms='alfa,betta,with\,with\',with space'}symbol}}
> {{}}
> [https://lucene.apache.org/solr/guide/6_6/faceting.html]
>  
> Just like prefix parameter in json.facet I think we can add terms parameter 
> and use it. Something like below.
>  
> json.facet=\{facets:{type:terms,field:field1,terms:"a,b,c"}}
>  
>  



--
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] [Updated] (SOLR-14921) terms filter in json.facet

2020-10-09 Thread gopikannan venugopalsamy (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

gopikannan venugopalsamy updated SOLR-14921:

Labels:   (was: newbe)

> terms filter in json.facet
> --
>
> Key: SOLR-14921
> URL: https://issues.apache.org/jira/browse/SOLR-14921
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: gopikannan venugopalsamy
>Priority: Major
>
> Hi,
>   In normal facet request below can be used to filter the facet terms. I am 
> not able to do the same using json.facet. It would be useful in case of 
> multivalued field facet and only filtered terms needs to be returned.
>  
> h3. Limiting Facet with Certain Terms
> To limit field facet with certain terms specify them comma separated with 
> {{terms}} local parameter. Commas and quotes in terms can be escaped with 
> backslash, as in {{\,}}. In this case facet is calculated on a way similar to 
> {{facet.method=enum}} , but ignores {{facet.enum.cache.minDf}}. For example:
> {{facet.field=\{!terms='alfa,betta,with\,with\',with space'}symbol}}
> {{}}
> [https://lucene.apache.org/solr/guide/6_6/faceting.html]
>  
> Just like prefix parameter in json.facet I think we can add terms parameter 
> and use it. Something like below.
>  
> json.facet=\{facets:{type:terms,field:field1,terms:"a,b,c"}}
>  
>  



--
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] ctargett commented on pull request #1865: SOLR-14862: Update RefGuide page for support fied types

2020-10-09 Thread GitBox



ctargett commented on pull request #1865:
URL: https://github.com/apache/lucene-solr/pull/1865#issuecomment-706288107


   FYI, the field type doc improvements weren't backported to branch_8x which 
caused me merge conflicts with some other general cleanups I did on master and 
wanted to backport. I don't know of a reason not to backport them, so as part 
of fixing my merge conflicts I'm going to make branch_8x the same as master for 
that file. Please let me know if the information is not the same in 8.7 so we 
can fix that before release.
   
   This means the other change in this PR to document the Ranking Parser is not 
in branch_8x either and I don't intend to chase that down to backport 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.

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] (SOLR-14921) terms filter in json.facet

2020-10-09 Thread gopikannan venugopalsamy (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211172#comment-17211172
 ] 

gopikannan venugopalsamy commented on SOLR-14921:
-

[~mgibney]

> terms filter in json.facet
> --
>
> Key: SOLR-14921
> URL: https://issues.apache.org/jira/browse/SOLR-14921
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: gopikannan venugopalsamy
>Priority: Minor
>
> Hi,
>   In normal facet request below can be used to filter the facet terms. I am 
> not able to do the same using json.facet. It would be useful in case of 
> multivalued field facet and only filtered terms needs to be returned.
>  
> h3. Limiting Facet with Certain Terms
> To limit field facet with certain terms specify them comma separated with 
> {{terms}} local parameter. Commas and quotes in terms can be escaped with 
> backslash, as in {{\,}}. In this case facet is calculated on a way similar to 
> {{facet.method=enum}} , but ignores {{facet.enum.cache.minDf}}. For example:
> {{facet.field=\{!terms='alfa,betta,with\,with\',with space'}symbol}}
> {{}}
> [https://lucene.apache.org/solr/guide/6_6/faceting.html]
>  
> Just like prefix parameter in json.facet I think we can add terms parameter 
> and use it. Something like below.
>  
> json.facet=\{facets:{type:terms,field:field1,terms:"a,b,c"}}
>  
>  



--
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] ctargett commented on pull request #1865: SOLR-14862: Update RefGuide page for support fied types

2020-10-09 Thread GitBox



ctargett commented on pull request #1865:
URL: https://github.com/apache/lucene-solr/pull/1865#issuecomment-706294638


   > This means the other change in this PR to document the Ranking Parser is 
not in branch_8x either and I don't intend to chase that down to backport it.
   
   Scratch that. The field type changes have a link to the docs so I have to 
bring that back too.



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] [Assigned] (LUCENE-9434) Update release step to remove creating a wiki page for every Solr release

2020-10-09 Thread Jason Gerlowski (Jira)



 [ 
https://issues.apache.org/jira/browse/LUCENE-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Gerlowski reassigned LUCENE-9434:
---

Assignee: Jason Gerlowski

> Update release step to remove creating a wiki page for every Solr release
> -
>
> Key: LUCENE-9434
> URL: https://issues.apache.org/jira/browse/LUCENE-9434
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Cassandra Targett
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: LUCENE-9434.patch
>
>
> The release TODO asks RMs to create a Wiki page in Confluence for each Solr 
> release 
> (https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-UpdateWIKI).
>  This page is often simply the date the release went out, and a link to the 
> release announcement (like this: 
> https://cwiki.apache.org/confluence/display/SOLR/Solr8.6) and an empty Errata 
> section I would guess never gets filled out.
> Many more details for a release are provided in the Release Notes page that's 
> created and also in the Solr Ref Guide's upgrade notes page. While I'm sure 
> this other page served a purpose at one time, it seems pointless today to 
> keep creating it.
> I propose we remove it from the wiki's ReleaseTODO and also from the Release 
> Wizard. I'll take a stab at making a patch to remove it from the wizard.



--
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-14656) Deprecate current autoscaling framework, remove from master

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211234#comment-17211234
 ] 

ASF subversion and git services commented on SOLR-14656:


Commit bd1e8a717fd6959568dfedaa1a5bd519f0ef9bce in lucene-solr's branch 
refs/heads/reference_impl_dev from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bd1e8a7 ]

SOLR-14656: Removing Autoscaling Framework

The following were removed:
 *  Autoscaling policy, triggers etc.
 *  withCollection handling
 *  UTILIZENODE command
 *  Sim framework
 *  Suggestions tab in UI
 *  Reference guide pages for autoscaling
 *  autoAddReplicas feature
 *  UTILIZENODE


> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Assignee: Andrzej Bialecki
>Priority: Blocker
> Fix For: 8.7
>
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP: 
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed 
> and too bloated and doesn't receive the level of support we aspire to provide 
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can 
> focus on the new autoscaling framework afresh.



--
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-14921) terms filter in json.facet

2020-10-09 Thread Michael Gibney (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211246#comment-17211246
 ] 

Michael Gibney commented on SOLR-14921:
---

Thanks for raising this, [~gopikannan]. Some context (adapted from a 
[conversation on the dev 
list|http://mail-archives.apache.org/mod_mbox/lucene-dev/202010.mbox/%3CCAF%3DheHGKwGtvq%3DgAndmVrgvo1cxKmzP0neGi17_eoVhubpaBZA%40mail.gmail.com%3E]):

The behavior you're seeking is already achievable by creating multiple 
json.facet queries – {{q="\{!term f=field v='Some term'}"}} – and sorting them 
client-side (if applicable). This works nicely because you're inherently 
dealing with a limited number of values; but it's relatively verbose, and in 
order to logically group related facet queries, I've ended up as a workaround 
nesting them all under a dummy parent facet query ({{q='\*:\*'}}) – not ideal:
{noformat}
json.facet = {
  group: {
type: query,
q: "*:*"
facet: {
  alfa: {
type: query,
q: "{!term f=symbol v=alfa}"
  },
  betta: {
type: query,
q: "{!term f=symbol v=alfa}"
  },
  with_space: {
type: query,
q: "{!term f=symbol v='with,with\',with space'}"
  }
}
  }
}
{noformat}
What I'm considering as a potential solution could be more generally thought of 
as "templated bucketed facet query", and would probably be more based on the 
{{FacetQueryProcessor}}, and could work for cases other than an explicit term 
list. It might look something like this:
{noformat}
json.facet = {
  symbol: {
type: template,
sort: 'count desc',
template: {
  type: query,
  q: '{!term f=symbol v=$var}' # different semantics from normal parameter 
substitution; alternatives?
},
buckets: [
  { var: alfa },
  { var: betta },
  { var: "with,with',with space" }
]
  }
}
{noformat}
Syntax could optionally be shortened by convention, e.g.:
{noformat}
json.facet = {
  symbol: {
type: template,
sort: 'count desc',
template: {
  type: query,
  q: '{!term f=symbol v=$var}'
},
buckets: [ "alfa", "betta", "with,with',with space" ] # or maybe make the 
key the name of the substitution, i.e. 'var'?
  }
}
{noformat}
But the more full syntax, supporting multiple variables, could be really 
powerful, e.g.:
{noformat}
json.facet = {
  symbol: {
type: template,
sort: 'skg desc',
template: {
  type: query,
  q: '{!v=$arbitrary_q}'
  facet: {
skg: {
  type: func,
  func: 'relatedness($fore,$back)',
  min_popularity: 0.001
}
  }
},
buckets: [
  {
val: history_of_science, # bucket label/val
arbitrary_q: "{!term f=topic_facet v='History of science'}"
  },
  {
val: accounting,
arbitrary_q: "{!term f=topic_keyword v=accounting}"
  },
  {
val: engineering_and_computer_science,
arbitrary_q: "{!bool should='{!term f=topic_keyword v=engineering}' 
should='{!prefix f=topic_facet v=\'Computer \'}'}"
  }
]
  }
}
{noformat}

I'm curious to know your (and others') thoughts on this. I'm also curious to 
know how you'd go about implementing this in a way based on 
{{FacetFieldProcessor}} ... iirc it's mainly focused on collection across the 
domain, and this functionality would essentially turn the request into "all 
refinement requests" -- at which point it's arguably more similar to 
{{FacetQueryProcessor}}.

> terms filter in json.facet
> --
>
> Key: SOLR-14921
> URL: https://issues.apache.org/jira/browse/SOLR-14921
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: gopikannan venugopalsamy
>Priority: Minor
>
> Hi,
>   In normal facet request below can be used to filter the facet terms. I am 
> not able to do the same using json.facet. It would be useful in case of 
> multivalued field facet and only filtered terms needs to be returned.
>  
> h3. Limiting Facet with Certain Terms
> To limit field facet with certain terms specify them comma separated with 
> {{terms}} local parameter. Commas and quotes in terms can be escaped with 
> backslash, as in {{\,}}. In this case facet is calculated on a way similar to 
> {{facet.method=enum}} , but ignores {{facet.enum.cache.minDf}}. For example:
> {{facet.field=\{!terms='alfa,betta,with\,with\',with space'}symbol}}
> {{}}
> [https://lucene.apache.org/solr/guide/6_6/faceting.html]
>  
> Just like prefix parameter in json.facet I think we can add terms parameter 
> and use it. Something like below.
>  
> json.facet=\{facets:{type:terms,field:field1,terms:"a,b,c"}}
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-

[jira] [Commented] (LUCENE-9434) Update release step to remove creating a wiki page for every Solr release

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211268#comment-17211268
 ] 

ASF subversion and git services commented on LUCENE-9434:
-

Commit 80df6a3d62cfacf6144f17a04447cf7707de6de1 in lucene-solr's branch 
refs/heads/master from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=80df6a3 ]

LUCENE-9434: Remove wiki-update step from release


> Update release step to remove creating a wiki page for every Solr release
> -
>
> Key: LUCENE-9434
> URL: https://issues.apache.org/jira/browse/LUCENE-9434
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Cassandra Targett
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: LUCENE-9434.patch
>
>
> The release TODO asks RMs to create a Wiki page in Confluence for each Solr 
> release 
> (https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-UpdateWIKI).
>  This page is often simply the date the release went out, and a link to the 
> release announcement (like this: 
> https://cwiki.apache.org/confluence/display/SOLR/Solr8.6) and an empty Errata 
> section I would guess never gets filled out.
> Many more details for a release are provided in the Release Notes page that's 
> created and also in the Solr Ref Guide's upgrade notes page. While I'm sure 
> this other page served a purpose at one time, it seems pointless today to 
> keep creating it.
> I propose we remove it from the wiki's ReleaseTODO and also from the Release 
> Wizard. I'll take a stab at making a patch to remove it from the wizard.



--
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-9434) Update release step to remove creating a wiki page for every Solr release

2020-10-09 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211271#comment-17211271
 ] 

ASF subversion and git services commented on LUCENE-9434:
-

Commit f1fccfbf7e84169330fc8df2fe2f56243cb8641a in lucene-solr's branch 
refs/heads/branch_8x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f1fccfb ]

LUCENE-9434: Remove wiki-update step from release


> Update release step to remove creating a wiki page for every Solr release
> -
>
> Key: LUCENE-9434
> URL: https://issues.apache.org/jira/browse/LUCENE-9434
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Cassandra Targett
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: LUCENE-9434.patch
>
>
> The release TODO asks RMs to create a Wiki page in Confluence for each Solr 
> release 
> (https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-UpdateWIKI).
>  This page is often simply the date the release went out, and a link to the 
> release announcement (like this: 
> https://cwiki.apache.org/confluence/display/SOLR/Solr8.6) and an empty Errata 
> section I would guess never gets filled out.
> Many more details for a release are provided in the Release Notes page that's 
> created and also in the Solr Ref Guide's upgrade notes page. While I'm sure 
> this other page served a purpose at one time, it seems pointless today to 
> keep creating it.
> I propose we remove it from the wiki's ReleaseTODO and also from the Release 
> Wizard. I'll take a stab at making a patch to remove it from the wizard.



--
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] ctargett commented on pull request #1923: SOLR-14900: Reference Guide build cleanup/module upgrade

2020-10-09 Thread GitBox



ctargett commented on pull request #1923:
URL: https://github.com/apache/lucene-solr/pull/1923#issuecomment-706344707


   +1 this looks good. I think the `solr/solr-ref-guide/README.adoc` also needs 
to be updated, though. This just occurred to me today, sorry to add another 
thing. It's really out of date since the move to Gradle so if you prefer to go 
ahead with merging this I can pick up fixing the README separately. Up to you.
   
   When I ran Jekyll locally in my earlier work with this, I needed to upgrade 
Ruby to 2.7 (the one that came with my OS was 2.3.x). Jekyll 3 does not run on 
Ruby 2.7, so if we don't make parallel changes in branch_8x for the Ant build, 
we'll get ourselves stuck when we need to do local builds for 8.x releases of 
the Ref Guide (it's been a pain today!). I'll take a stab at a new PR on this 
same SOLR-14900 for that.



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] barrotsteindev opened a new pull request #1970: SOLR-14869: do not add deleted docs in child doc transformer

2020-10-09 Thread GitBox



barrotsteindev opened a new pull request #1970:
URL: https://github.com/apache/lucene-solr/pull/1970


   
   
   
   # Description
   
   Please provide a short description of the changes you're making with this 
pull request.
   
   # Solution
   
   Please provide a short description of the approach taken to implement your 
solution.
   
   # Tests
   
   Please describe the tests you've developed or run to confirm this patch 
implements the feature or solves the problem.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [x] I have developed this patch against the `master` branch.
   - [x] I have run `./gradlew check`.
   - [x] I have added tests for my changes.
   - [x] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   



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-9434) Update release step to remove creating a wiki page for every Solr release

2020-10-09 Thread Jason Gerlowski (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211299#comment-17211299
 ] 

Jason Gerlowski commented on LUCENE-9434:
-

I removed the whitespace changes from Cassandra's patch, tested out that it 
resulted in the right change to the release wizard menus, and committed to 
master and 8x.  Closing this out accordingly.

> Update release step to remove creating a wiki page for every Solr release
> -
>
> Key: LUCENE-9434
> URL: https://issues.apache.org/jira/browse/LUCENE-9434
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Cassandra Targett
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: LUCENE-9434.patch
>
>
> The release TODO asks RMs to create a Wiki page in Confluence for each Solr 
> release 
> (https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-UpdateWIKI).
>  This page is often simply the date the release went out, and a link to the 
> release announcement (like this: 
> https://cwiki.apache.org/confluence/display/SOLR/Solr8.6) and an empty Errata 
> section I would guess never gets filled out.
> Many more details for a release are provided in the Release Notes page that's 
> created and also in the Solr Ref Guide's upgrade notes page. While I'm sure 
> this other page served a purpose at one time, it seems pointless today to 
> keep creating it.
> I propose we remove it from the wiki's ReleaseTODO and also from the Release 
> Wizard. I'll take a stab at making a patch to remove it from the wizard.



--
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] [Resolved] (LUCENE-9434) Update release step to remove creating a wiki page for every Solr release

2020-10-09 Thread Jason Gerlowski (Jira)



 [ 
https://issues.apache.org/jira/browse/LUCENE-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Gerlowski resolved LUCENE-9434.
-
Fix Version/s: 8.7
   master (9.0)
   Resolution: Fixed

> Update release step to remove creating a wiki page for every Solr release
> -
>
> Key: LUCENE-9434
> URL: https://issues.apache.org/jira/browse/LUCENE-9434
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Cassandra Targett
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: master (9.0), 8.7
>
> Attachments: LUCENE-9434.patch
>
>
> The release TODO asks RMs to create a Wiki page in Confluence for each Solr 
> release 
> (https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-UpdateWIKI).
>  This page is often simply the date the release went out, and a link to the 
> release announcement (like this: 
> https://cwiki.apache.org/confluence/display/SOLR/Solr8.6) and an empty Errata 
> section I would guess never gets filled out.
> Many more details for a release are provided in the Release Notes page that's 
> created and also in the Solr Ref Guide's upgrade notes page. While I'm sure 
> this other page served a purpose at one time, it seems pointless today to 
> keep creating it.
> I propose we remove it from the wiki's ReleaseTODO and also from the Release 
> Wizard. I'll take a stab at making a patch to remove it from the wizard.



--
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-14869) [child] transformer includes deleted documents

2020-10-09 Thread Bar Rotstein (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211300#comment-17211300
 ] 

Bar Rotstein commented on SOLR-14869:
-

[~dsmiley] 
Opened a PR, hopefully I took care of all the edge cases.
It's been a while since I've touched Solr's codebase.

> [child] transformer includes deleted documents
> --
>
> Key: SOLR-14869
> URL: https://issues.apache.org/jira/browse/SOLR-14869
> Project: Solr
>  Issue Type: Bug
>Reporter: Chris M. Hostetter
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If you have nested documents that include "deleted" docs (ie: using "delete 
> by query") the {{\[child\]}} transformer still include those deleted docs i 
> it's output



--
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-9576) IndexWriter::commit() hangs when the server has a stale NFS mount.

2020-10-09 Thread Girish Nayak (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211313#comment-17211313
 ] 

Girish Nayak commented on LUCENE-9576:
--

Thanks [~rcmuir]. This is helpful.

> IndexWriter::commit() hangs when the server has a stale NFS mount.
> --
>
> Key: LUCENE-9576
> URL: https://issues.apache.org/jira/browse/LUCENE-9576
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 8.5.2
>Reporter: Girish Nayak
>Priority: Major
> Attachments: IndexWriter-commit.PNG
>
>
> Noticed IndexWriter::commit() hangs when the server has one or more stale NFS 
> mounts.
>  



--
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] dweiss commented on pull request #1968: LUCENE-9562: Unify 'analysis' package with produced artifact names (-analyzers- to -analysis-)

2020-10-09 Thread GitBox



dweiss commented on pull request #1968:
URL: https://github.com/apache/lucene-solr/pull/1968#issuecomment-706378553


   Correct, no backport planned to 8x.



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] ctargett opened a new pull request #1971: SOLR-14900: 8.x changes to update Jekyll

2020-10-09 Thread GitBox



ctargett opened a new pull request #1971:
URL: https://github.com/apache/lucene-solr/pull/1971


   PR #1923 will upgrade Jekyll to 4.x for the master branch. I propose to do 
the same thing with our Ant build in branch_8x. This also fixes the code syntax 
styling bug fixed in the other PR and updates the README.adoc to reflect the 
new version requirements.
   
   I don't intend to merge this until _after_ 8.7 is released because it will 
require anyone who wants to build the Ref Guide in 8.x to upgrade Ruby to at 
least 2.5 (if it's not already) and upgrade Jekyll. If someone is trying to do 
something quick I don't want to slow them down.



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] madrob commented on a change in pull request #1963: SOLR-14827: Refactor schema loading to not use XPath

2020-10-09 Thread GitBox



madrob commented on a change in pull request #1963:
URL: https://github.com/apache/lucene-solr/pull/1963#discussion_r502660921



##
File path: solr/core/src/java/org/apache/solr/util/DOMUtil.java
##
@@ -39,9 +42,23 @@
 
   public static final String XML_RESERVED_PREFIX = "xml";
 
+  static final Set  NL_TAGS = ImmutableSet.of("str", 
"int","long","float","double","bool");

Review comment:
   can we use Set.of instead of ImmutableSet

##
File path: solr/solrj/src/java/org/apache/solr/common/ConfigNode.java
##
@@ -0,0 +1,90 @@
+/*
+ * 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.solr.common;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+import java.util.Set;
+import java.util.function.Function;
+import java.util.function.Predicate;
+
+import org.apache.solr.cluster.api.SimpleMap;
+
+/**
+ * A generic interface that represents a config file, mostly XML
+ */
+public interface ConfigNode {
+  ThreadLocal> SUBSTITUTES = new ThreadLocal<>();

Review comment:
   this probably needs to be static.

##
File path: solr/core/src/java/org/apache/solr/schema/IndexSchema.java
##
@@ -537,26 +554,30 @@ protected void readSchema(InputSource is) {
   }
 
   //  /schema/defaultSearchField/text()
-  expression = stepsToPath(SCHEMA, "defaultSearchField", TEXT_FUNCTION);
-  node = (Node) xpath.evaluate(expression, document, XPathConstants.NODE);
+//  expression = stepsToPath(SCHEMA, "defaultSearchField", TEXT_FUNCTION);
+//  node = (Node) xpath.evaluate(expression, document, 
XPathConstants.NODE);
+  ConfigNode node = rootNode.child("defaultSearchField");
   if (node != null) {
 throw new SolrException(ErrorCode.SERVER_ERROR, "Setting 
defaultSearchField in schema not supported since Solr 7");
   }
+  node = rootNode.child("solrQueryParser");

Review comment:
   missing `@defaultOperator`?

##
File path: solr/solrj/src/java/org/apache/solr/common/ConfigNode.java
##
@@ -0,0 +1,90 @@
+/*
+ * 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.solr.common;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+import java.util.Set;
+import java.util.function.Function;
+import java.util.function.Predicate;
+
+import org.apache.solr.cluster.api.SimpleMap;
+
+/**
+ * A generic interface that represents a config file, mostly XML
+ */
+public interface ConfigNode {
+  ThreadLocal> SUBSTITUTES = new ThreadLocal<>();
+
+  /**
+   * Name of the tag
+   */
+  String name();
+
+  /**
+   * Text value of the node
+   */
+  String textValue();
+
+  /**
+   * Attributes
+   */
+  SimpleMap attributes();
+
+  /**
+   * Child by name
+   */
+  default ConfigNode child(String name) {
+return child(null, name);
+  }
+
+  default ConfigNode child(Predicate test, String name) {
+ConfigNode[] result = new ConfigNode[1];
+forEachChild(it -> {
+  if (name!=null && !name.equals(it.name())) return Boolean.TRUE;
+  if (test == null || test.test(it)) {
+result[0] = it;
+return Boolean.FALSE;
+  }
+  return Boolean.TRUE;
+});
+return result[0];
+  }
+
+  default List children(Predicate test, String... 
nodeNames) {
+return children(test, nodeNames == null ? Collections.emptySet() : 
Set.of(nodeNames));
+  }
+
+  default List children(Predicate test, Set 
s

[GitHub] [lucene-solr] madrob commented on pull request #1963: SOLR-14827: Refactor schema loading to not use XPath

2020-10-09 Thread GitBox



madrob commented on pull request #1963:
URL: https://github.com/apache/lucene-solr/pull/1963#issuecomment-706398269


   I'm still looking through this, but there's a lot of code commented out that 
makes me think it is still in progress. Give a shout when it's ready for review.



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] (SOLR-14844) Upgrade Jetty to 9.4.32.v20200930

2020-10-09 Thread Erick Erickson (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211435#comment-17211435
 ] 

Erick Erickson commented on SOLR-14844:
---

Same problem with BasicHttpSolrClientTest.testCompression, I guess I'll have 
to, you know, actually look at the test...

> Upgrade Jetty to 9.4.32.v20200930
> -
>
> Key: SOLR-14844
> URL: https://issues.apache.org/jira/browse/SOLR-14844
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6
>Reporter: Cassandra Targett
>Assignee: Erick Erickson
>Priority: Major
>
> A CVE was found in Jetty 9.4.27-9.4.29 that has some security scanning tools 
> raising red flags 
> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17638]).
> Here's the Jetty issue: 
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984]. It's fixed in 
> 9.4.30+, so we should upgrade to that for 8.7
> -It has a simple mitigation (raise Jetty's responseHeaderSize to higher than 
> requestHeaderSize), but I don't know how Solr uses Jetty well enough to a) 
> know if this problem is even exploitable in Solr, or b) if the workaround 
> suggested is even possible in Solr.-
> In normal Solr installs, w/o jetty optimizations, this issue is largely 
> mitigated in 8.6.3: see SOLR-14896 (and linked bug fixes) for details.



--
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] [Updated] (LUCENE-9577) Move HTML Documentation to a separate subproject

2020-10-09 Thread Uwe Schindler (Jira)



 [ 
https://issues.apache.org/jira/browse/LUCENE-9577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-9577:
--
Fix Version/s: master (9.0)

> Move HTML Documentation to a separate subproject
> 
>
> Key: LUCENE-9577
> URL: https://issues.apache.org/jira/browse/LUCENE-9577
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently Lucene/Solr have some subdirectory "site" containing some fragments 
> for CHANGES.txt formatting and the Markdown to produce the site. The global 
> documentation for both Lucene and Solr should be built with its own 
> subproject {{:lucene:documentation}} and {{:solr:documentation}}.
> I will provide a PR that does the following:
> - Move Changes.html formatting scripts to gradle subfolder, so they are 
> correctly shared between Lucene and Gradle and allows to split project 
> (currently they live in Lucene only)
> - Move the site contents with correct names a {{src/assets}}, 
> {{src/markdown}} into the new documentation projects
> - Make packaging of documentation in the projects build.gradle. 
> {{:lucene:documentation:assemble}} should assemble the documentation (same 
> for Solr) and export it as configuration
> - The main packaging will use the artifacts provided to put it into TGZ. Also 
> Release manager can build documentation using the above gradlew calls.



--
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] [Updated] (SOLR-14870) gradle build does not validate ref-guide -> javadoc links

2020-10-09 Thread Chris M. Hostetter (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris M. Hostetter updated SOLR-14870:
--
Status: Patch Available  (was: Open)

> gradle build does not validate ref-guide -> javadoc links
> -
>
> Key: SOLR-14870
> URL: https://issues.apache.org/jira/browse/SOLR-14870
> Project: Solr
>  Issue Type: Task
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14870.patch, SOLR-14870.patch
>
>
> the ant build had (has on 8x) a feature that ensured we didn't have any 
> broken links between the ref guide and the javadocs...
> {code}
>  depends="javadocs,changes-to-html,process-webpages">
>  inheritall="false">
>   
>   
> 
>   
> {code}
> ...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}} 
> just did interanal validation of the strucure of the guide, but this hook 
> ment that {{cd solr && ant documentation}} (or {{ant precommit}}) would first 
> build the javadocs; then build the ref-guide; then validate _all_ links i 
> nthe ref-guide, even those to (local) javadocs
> While the "local.javadocs" property logic _inside_ the 
> solr-ref-guide/build.xml was ported to build.gradle, the logic to leverage 
> this functionality from the "solr" project doesn't seem to have been 
> preserved -- so currently, {{gradle check}} doesn't know/care if someone adds 
> a nonsense javadoc link to the ref-guide (or removes a class/method whose 
> javadoc is already currently to from the ref guide)



--
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] [Updated] (SOLR-14870) gradle build does not validate ref-guide -> javadoc links

2020-10-09 Thread Chris M. Hostetter (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris M. Hostetter updated SOLR-14870:
--
Attachment: SOLR-14870.patch
Status: Open  (was: Open)

patch updated to resolve nocommits and correct links in adoc files that point 
to javadocs which have moved (due to documenation/javadoc directory structure 
re-org).

top level "gradle check" now correctly fails if there is an incorrect javadoc 
link in the ref-guide.

I'll plan on committing monday.

> gradle build does not validate ref-guide -> javadoc links
> -
>
> Key: SOLR-14870
> URL: https://issues.apache.org/jira/browse/SOLR-14870
> Project: Solr
>  Issue Type: Task
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14870.patch, SOLR-14870.patch
>
>
> the ant build had (has on 8x) a feature that ensured we didn't have any 
> broken links between the ref guide and the javadocs...
> {code}
>  depends="javadocs,changes-to-html,process-webpages">
>  inheritall="false">
>   
>   
> 
>   
> {code}
> ...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}} 
> just did interanal validation of the strucure of the guide, but this hook 
> ment that {{cd solr && ant documentation}} (or {{ant precommit}}) would first 
> build the javadocs; then build the ref-guide; then validate _all_ links i 
> nthe ref-guide, even those to (local) javadocs
> While the "local.javadocs" property logic _inside_ the 
> solr-ref-guide/build.xml was ported to build.gradle, the logic to leverage 
> this functionality from the "solr" project doesn't seem to have been 
> preserved -- so currently, {{gradle check}} doesn't know/care if someone adds 
> a nonsense javadoc link to the ref-guide (or removes a class/method whose 
> javadoc is already currently to from the ref guide)



--
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-14870) gradle build does not validate ref-guide -> javadoc links

2020-10-09 Thread Uwe Schindler (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211449#comment-17211449
 ] 

Uwe Schindler commented on SOLR-14870:
--

Hi, did you include my latest commit on master du to packaging changes? I fixed 
the relative links ("link:") already on mast so build reported incorrect links 
(if enabled).

> gradle build does not validate ref-guide -> javadoc links
> -
>
> Key: SOLR-14870
> URL: https://issues.apache.org/jira/browse/SOLR-14870
> Project: Solr
>  Issue Type: Task
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14870.patch, SOLR-14870.patch
>
>
> the ant build had (has on 8x) a feature that ensured we didn't have any 
> broken links between the ref guide and the javadocs...
> {code}
>  depends="javadocs,changes-to-html,process-webpages">
>  inheritall="false">
>   
>   
> 
>   
> {code}
> ...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}} 
> just did interanal validation of the strucure of the guide, but this hook 
> ment that {{cd solr && ant documentation}} (or {{ant precommit}}) would first 
> build the javadocs; then build the ref-guide; then validate _all_ links i 
> nthe ref-guide, even those to (local) javadocs
> While the "local.javadocs" property logic _inside_ the 
> solr-ref-guide/build.xml was ported to build.gradle, the logic to leverage 
> this functionality from the "solr" project doesn't seem to have been 
> preserved -- so currently, {{gradle check}} doesn't know/care if someone adds 
> a nonsense javadoc link to the ref-guide (or removes a class/method whose 
> javadoc is already currently to from the ref guide)



--
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-14870) gradle build does not validate ref-guide -> javadoc links

2020-10-09 Thread Chris M. Hostetter (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211451#comment-17211451
 ] 

Chris M. Hostetter commented on SOLR-14870:
---

yes – patch is up to date with master and includes the 
{{relativize(project(':solr:documentation').docroot.toPath())}} style logic.

> gradle build does not validate ref-guide -> javadoc links
> -
>
> Key: SOLR-14870
> URL: https://issues.apache.org/jira/browse/SOLR-14870
> Project: Solr
>  Issue Type: Task
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14870.patch, SOLR-14870.patch
>
>
> the ant build had (has on 8x) a feature that ensured we didn't have any 
> broken links between the ref guide and the javadocs...
> {code}
>  depends="javadocs,changes-to-html,process-webpages">
>  inheritall="false">
>   
>   
> 
>   
> {code}
> ...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}} 
> just did interanal validation of the strucure of the guide, but this hook 
> ment that {{cd solr && ant documentation}} (or {{ant precommit}}) would first 
> build the javadocs; then build the ref-guide; then validate _all_ links i 
> nthe ref-guide, even those to (local) javadocs
> While the "local.javadocs" property logic _inside_ the 
> solr-ref-guide/build.xml was ported to build.gradle, the logic to leverage 
> this functionality from the "solr" project doesn't seem to have been 
> preserved -- so currently, {{gradle check}} doesn't know/care if someone adds 
> a nonsense javadoc link to the ref-guide (or removes a class/method whose 
> javadoc is already currently to from the ref guide)



--
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-9524) NullPointerException in IndexSearcher.explain() when using ComplexPhraseQueryParser

2020-10-09 Thread Zach Chen (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211490#comment-17211490
 ] 

Zach Chen commented on LUCENE-9524:
---

So after much debugging and tracing, I found that revert-ting the one-line 
change from https://issues.apache.org/jira/browse/LUCENE-7238 would resolve 
this NPE issue, but not sure if this is the right approach to be taken here.

The underlying issue causing the differences in behavior is that,  the *NOT 
\"dolor lorem\"* in the query above would generate a _SpanNearWeight_ with 
ScoreMode _COMPLETE_NO_SCORES_ for both cases. However, when _LRUQueryCache_ is 
available for non MemoryIndex, this weight gets wrapped into 
_LRUQueryCache$CachingWrapperWeight_, which extends _ConstantScoreWeight_ and 
doesn't use (the null) simScorer for explanation.

So it seems like the use of _LRUQueryCache$CachingWrapperWeight_ can make the 
underlying potentially variable-score weight to be constant-score weight for 
explanation. 

On the other hand, _SpanNearWeight's_ super class _SpanWight_ seems to allow 
null simScorer field, but its explanation method's call to _LeafSimScorer_ 
constructor doesn't check for the case of null simScorer. Maybe a check is 
needed there as well?


 [~jpountz] Sine from git you worked on both aspects above, I'm wondering 
what's your take on this? I can work on a patch if needed.
  

> NullPointerException in IndexSearcher.explain() when using 
> ComplexPhraseQueryParser
> ---
>
> Key: LUCENE-9524
> URL: https://issues.apache.org/jira/browse/LUCENE-9524
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser, core/search
>Affects Versions: 8.6, 8.6.2
>Reporter: Michał Słomkowski
>Priority: Major
>
> I get NPE when I use {{IndexSearcher.explain()}}. Checked with Lucene 8.6.0
> and 8.6.2.
> The query: {{(lorem AND NOT "dolor lorem") OR ipsum}}
> The text: {{dolor lorem ipsum}}
> Stack trace:
> {code}
> java.lang.NullPointerException at 
> java.util.Objects.requireNonNull(Objects.java:203)
>   at org.apache.lucene.search.LeafSimScorer.(LeafSimScorer.java:38)
>   at 
> org.apache.lucene.search.spans.SpanWeight.explain(SpanWeight.java:160)
>   at org.apache.lucene.search.BooleanWeight.explain(BooleanWeight.java:87)
>   at org.apache.lucene.search.BooleanWeight.explain(BooleanWeight.java:87)
>   at 
> org.apache.lucene.search.IndexSearcher.explain(IndexSearcher.java:716)
>   at 
> org.apache.lucene.search.IndexSearcher.explain(IndexSearcher.java:693)
> {code}
> Minimal example code:
> {code:java}
> val analyzer = new StandardAnalyzer();
> val query = new ComplexPhraseQueryParser("", analyzer).parse(queryString);
> final MemoryIndex memoryIndex = new MemoryIndex(true);
> memoryIndex.addField("", text, analyzer);
> final IndexSearcher searcher = memoryIndex.createSearcher();
> final TopDocs topDocs = searcher.search(query, 1);
> final ScoreDoc match = topDocs.scoreDocs[0];
> searcher.explain(query, match.doc);
> {code}



--
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-9560) Position aware TermQuery

2020-10-09 Thread Haoyu Zhai (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211544#comment-17211544
 ] 

Haoyu Zhai commented on LUCENE-9560:


Thanks guys. I tried and did find out that {{IntervalQuery}} provide the 
functionality I desire, I'll close this issue

> Position aware TermQuery
> 
>
> Key: LUCENE-9560
> URL: https://issues.apache.org/jira/browse/LUCENE-9560
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/search
>Reporter: Haoyu Zhai
>Priority: Major
>
> In our work, we index most of our fields into an "all" field (like 
> elasticsearch) to make our search faster. But at the same time we still want 
> to support some of the field specific search (like {{title}}), so currently 
> our solution is to double index them so that we could do both "all" search as 
> well as specific field search.
> I want to propose a new term query that accept a range in a specific field to 
> search so that we could search on "all" field but act like a field specific 
> search. Then we need not to doubly index those field.



--
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] [Resolved] (LUCENE-9560) Position aware TermQuery

2020-10-09 Thread Haoyu Zhai (Jira)



 [ 
https://issues.apache.org/jira/browse/LUCENE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Haoyu Zhai resolved LUCENE-9560.

Resolution: Not A Problem

> Position aware TermQuery
> 
>
> Key: LUCENE-9560
> URL: https://issues.apache.org/jira/browse/LUCENE-9560
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/search
>Reporter: Haoyu Zhai
>Priority: Major
>
> In our work, we index most of our fields into an "all" field (like 
> elasticsearch) to make our search faster. But at the same time we still want 
> to support some of the field specific search (like {{title}}), so currently 
> our solution is to double index them so that we could do both "all" search as 
> well as specific field search.
> I want to propose a new term query that accept a range in a specific field to 
> search so that we could search on "all" field but act like a field specific 
> search. Then we need not to doubly index those field.



--
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] dsmiley commented on a change in pull request #1970: SOLR-14869: do not add deleted docs in child doc transformer

2020-10-09 Thread GitBox



dsmiley commented on a change in pull request #1970:
URL: https://github.com/apache/lucene-solr/pull/1970#discussion_r502745875



##
File path: 
solr/core/src/test/org/apache/solr/response/transform/TestChildDocTransformerHierarchy.java
##
@@ -135,6 +135,37 @@ public void testParentFilterLimitJSON() throws Exception {
 );
   }
 
+  @Test
+  public void testLiveDocs() throws Exception {

Review comment:
   ```suggestion
 public void testWithDeletedChildren() throws Exception {
   ```
   
   "liveDocs" is Lucene level internal terminology.

##
File path: 
solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformer.java
##
@@ -126,6 +128,12 @@ public void transform(SolrDocument rootDoc, int rootDocId) 
{
   continue;
 }
 
+// check whether doc is "live"

Review comment:
   Maybe do this at the top of the loop because it's cheap?

##
File path: 
solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformer.java
##
@@ -126,6 +128,12 @@ public void transform(SolrDocument rootDoc, int rootDocId) 
{
   continue;
 }
 
+// check whether doc is "live"
+if (liveDocs != null && !liveDocs.get(docId)) {

Review comment:
   ```suggestion
   if (liveDocs != null && !liveDocs.get(docId - segBaseId)) {
   ```
   See if your test could have caught this by adding a doc & committing up 
front, thus creating an additional segment?  You could wrap in a 
random().nextBoolean()





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] noblepaul commented on a change in pull request #1963: SOLR-14827: Refactor schema loading to not use XPath

2020-10-09 Thread GitBox



noblepaul commented on a change in pull request #1963:
URL: https://github.com/apache/lucene-solr/pull/1963#discussion_r502753234



##
File path: solr/core/src/java/org/apache/solr/util/DOMUtil.java
##
@@ -39,9 +42,23 @@
 
   public static final String XML_RESERVED_PREFIX = "xml";
 
+  static final Set  NL_TAGS = ImmutableSet.of("str", 
"int","long","float","double","bool");

Review comment:
   `Set.of()` is java 9. I'm hoping to put this into Solr 8.x





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] noblepaul commented on a change in pull request #1963: SOLR-14827: Refactor schema loading to not use XPath

2020-10-09 Thread GitBox



noblepaul commented on a change in pull request #1963:
URL: https://github.com/apache/lucene-solr/pull/1963#discussion_r502753836



##
File path: solr/solrj/src/java/org/apache/solr/common/ConfigNode.java
##
@@ -0,0 +1,90 @@
+/*
+ * 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.solr.common;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+import java.util.Set;
+import java.util.function.Function;
+import java.util.function.Predicate;
+
+import org.apache.solr.cluster.api.SimpleMap;
+
+/**
+ * A generic interface that represents a config file, mostly XML
+ */
+public interface ConfigNode {
+  ThreadLocal> SUBSTITUTES = new ThreadLocal<>();

Review comment:
   It's an interface. All fields are `public static final` by default





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] noblepaul commented on pull request #1963: SOLR-14827: Refactor schema loading to not use XPath

2020-10-09 Thread GitBox



noblepaul commented on pull request #1963:
URL: https://github.com/apache/lucene-solr/pull/1963#issuecomment-706497962


   >, but there's a lot of code commented out that makes me think it is still 
in progress.
   
   I left that code there so that it is clear to the reviewer as to what is 
being replaced. Please go ahead w/ review. Once I'm ready to commit, I'll 
remove the commented code



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

97 matches

Mail list logo