[GitHub] [lucene-solr] juanka588 commented on a change in pull request #1818: SOLR-14819 Trivial fix to inefficient iterator pattern
juanka588 commented on a change in pull request #1818:
URL: https://github.com/apache/lucene-solr/pull/1818#discussion_r481841600
##
File path:
solr/solrj/src/java/org/apache/solr/common/util/JsonSchemaValidator.java
##
@@ -48,13 +48,15 @@ public JsonSchemaValidator(String jsonString) {
public JsonSchemaValidator(Map jsonSchema) {
this.validators = new LinkedList<>();
-for (Object fname : jsonSchema.keySet()) {
+for (Object entry : jsonSchema.entrySet()) {
Review comment:
use Map.Entry<> directly here
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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] [Created] (SOLR-14820) Create replica is broken
Thomas Wöckinger created SOLR-14820: --- Summary: Create replica is broken Key: SOLR-14820 URL: https://issues.apache.org/jira/browse/SOLR-14820 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: replication (java), Server Affects Versions: 8.6.2, 8.6.1, 8.5.2, 8.5.1, 8.6 Reporter: Thomas Wöckinger Creating an additional replica for a collection fails because live nodes are not valid -- 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-9496) Replace (or accelerate) check-broken-links.gradle with a doclet pass
[ https://issues.apache.org/jira/browse/LUCENE-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189045#comment-17189045 ] Tomoko Uchida commented on LUCENE-9496: --- bq. Maybe we could replace the python linter entirely; verify where code links will point at, where existing HTML links point to and validate this information. +1. Porting the external link checker script to Java code would be easier task than the missing docs check script, I think. I'd give it a try... > Replace (or accelerate) check-broken-links.gradle with a doclet pass > > > Key: LUCENE-9496 > URL: https://issues.apache.org/jira/browse/LUCENE-9496 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This is just a placeholder, but perhaps somebody will find the time to push > this forward. The current python script in check-broken-links reparses all > emitted HTML files to find links. I have a strong feeling this could be done > better. > Javadoc doclets have access to parse trees for both the code and the javadoc > comments (including information about HTML tags, code links, etc.). For > example, this information is used by the built-in javac HTML linter. > Maybe we could replace the python linter entirely; verify where code links > will point at, where existing HTML links point to and validate this > information. I wrote some of that link-parsing code in Carrot2 (to convert > javadocs into a structured JSON format used in other documentation). The code > there is free to eyeball and borrow, if needed. > https://docs.oracle.com/en/java/javase/11/docs/api/jdk.compiler/com/sun/source/util/DocTreeScanner.html > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/JavaDocsVisitor.java#L135 > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/PlainReferenceConverter.java -- 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-14820) Create replica is broken
[ https://issues.apache.org/jira/browse/SOLR-14820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189048#comment-17189048 ] Thomas Wöckinger commented on SOLR-14820: - Also found on stackoverflow [https://stackoverflow.com/questions/58528855/solr-cloud-add-replica-fails-on-node-thats-available-on-clusterstatus-live|http://example.com] > Create replica is broken > > > Key: SOLR-14820 > URL: https://issues.apache.org/jira/browse/SOLR-14820 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java), Server >Affects Versions: 8.6, 8.5.1, 8.5.2, 8.6.1, 8.6.2 >Reporter: Thomas Wöckinger >Priority: Critical > > Creating an additional replica for a collection fails because live nodes are > not valid -- 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-14820) Create replica is broken
[
https://issues.apache.org/jira/browse/SOLR-14820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189052#comment-17189052
]
Thomas Wöckinger commented on SOLR-14820:
-
Using API to get cluster state delivers correct values:
{code:java}
// {
"responseHeader":{
"status":0,
"QTime":4},
"cluster":{
"collections":{
"FY_XXX":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"FY_XXX_shard1_replica_n1",
"base_url":"https://10.133.48.65:8984/solr";,
"node_name":"10.133.48.65:8984_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0",
"znodeVersion":7,
"configName":"FY_XXX"},
"FY_INFO_XXX":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"FY_INFO_XXX_shard1_replica_n1",
"base_url":"https://10.133.48.65:8984/solr";,
"node_name":"10.133.48.65:8984_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0",
"znodeVersion":7,
"configName":"FY_INFO_XXX"}},
"properties":{"urlScheme":"https"},
"live_nodes":["10.133.48.64:8984_solr",
"10.133.48.66:8984_solr",
"10.133.48.65:8984_solr"]}}
{code}
{{}}
> Create replica is broken
>
>
> Key: SOLR-14820
> URL: https://issues.apache.org/jira/browse/SOLR-14820
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java), Server
>Affects Versions: 8.6, 8.5.1, 8.5.2, 8.6.1, 8.6.2
>Reporter: Thomas Wöckinger
>Priority: Critical
>
> Creating an additional replica for a collection fails because live nodes are
> not valid
--
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] [Comment Edited] (SOLR-14820) Create replica is broken
[
https://issues.apache.org/jira/browse/SOLR-14820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189052#comment-17189052
]
Thomas Wöckinger edited comment on SOLR-14820 at 9/2/20, 7:55 AM:
--
Using API to get cluster state delivers correct values:
{code:java}
// {
"responseHeader":{
"status":0,
"QTime":4},
"cluster":{
"collections":{
"FY_XXX":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"FY_XXX_shard1_replica_n1",
"base_url":"https://10.133.48.65:8984/solr";,
"node_name":"10.133.48.65:8984_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0",
"znodeVersion":7,
"configName":"FY_XXX"},
"FY_INFO_XXX":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"FY_INFO_XXX_shard1_replica_n1",
"base_url":"https://10.133.48.65:8984/solr";,
"node_name":"10.133.48.65:8984_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0",
"znodeVersion":7,
"configName":"FY_INFO_XXX"}},
"properties":{"urlScheme":"https"},
"live_nodes":["10.133.48.64:8984_solr",
"10.133.48.66:8984_solr",
"10.133.48.65:8984_solr"]}}
{code}
was (Author: thomas.woeckinger):
Using API to get cluster state delivers correct values:
{code:java}
// {
"responseHeader":{
"status":0,
"QTime":4},
"cluster":{
"collections":{
"FY_XXX":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"FY_XXX_shard1_replica_n1",
"base_url":"https://10.133.48.65:8984/solr";,
"node_name":"10.133.48.65:8984_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0",
"znodeVersion":7,
"configName":"FY_XXX"},
"FY_INFO_XXX":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"FY_INFO_XXX_shard1_replica_n1",
"base_url":"https://10.133.48.65:8984/solr";,
"node_name":"10.133.48.65:8984_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0",
"znodeVersion":7,
"configName":"FY_INFO_XXX"}},
"properties":{"urlScheme":"https"},
"live_nodes":["10.133.48.64:8984_solr",
"10.133.48.66:8984_solr",
"10.133.48.65:8984_solr"]}}
{code}
{{}}
> Create replica is broken
>
>
> Key: SOLR-14820
> URL: https://issues.apache.org/jira/browse/SOLR-14820
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java), Server
>Affects Versions: 8.6, 8.5.1, 8.5.2, 8.6.1, 8.6.2
>Reporter: Thomas Wöckinger
>Priority: Critical
>
> Creating an additional replica for a collection fails because live nodes are
> not valid
--
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 #1816: LUCENE-9497: Integerate Error Prone ( Static Analysis Tool ) during compilation
dweiss commented on pull request #1816: URL: https://github.com/apache/lucene-solr/pull/1816#issuecomment-685376959 Please move all of this plugin's related code to a separate snippet file, much like everything else gradle-related is shaped at the moment. 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-9495) Ref Guide gradle buildSite ignores version parameter
[
https://issues.apache.org/jira/browse/LUCENE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189027#comment-17189027
]
Dawid Weiss commented on LUCENE-9495:
-
> it's been renamed (probably to be more "gradle-esque" ?) using camel case:
> solrGuideVersion
It's a groovy variable; it'd be pretty awkward (or even impossible) to declare
it with dashes?
> it has to be specified using '-P' (which is evidently the gradle way of
> setting project properties on the command line
Correct. This was early work - we since use a closure propertyOrDefault which
resolves system properties as well as project properties. Could use that
instead to resolve the value.
> A lot of this was spelled out in the build.xml comments, but that info
> evidently wasn't preserved in the creation of build.gradle...
Very likely so. I admit I didn't care much about reading the ant code - all I
cared for the output to be pretty much identical. There are several TODO
entries in that gradle build file where I still felt things could be improved
but had to stick to ant compatibility (or didn't find enough motivation to do
so).
> Ref Guide gradle buildSite ignores version parameter
>
>
> Key: LUCENE-9495
> URL: https://issues.apache.org/jira/browse/LUCENE-9495
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Reporter: Cassandra Targett
>Priority: Major
>
> All Ref Guide builds by default are built as drafts. A DRAFT watermark is
> inserted on to every page, a special header is added to the side navigation,
> and the footer version includes the word "-DRAFT".
> To accomplish this, the guide has long used a parameter
> {{solr-guide-version}} to indicate when a build for the Ref Guide _should
> not_ be considered a draft. With the Gradle build, this no longer works. (I
> thought I'd tested this, but either I missed it or it broke at some point in
> between.)
> [~hossman] set this up several years ago, so cc'ing him here so he can take a
> look and see why the logic would stop working now.
> Links:
> Ref Guide {{build.gradle}} that determines Guide version:
> https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/build.gradle#L128
> Ant {{build.xml}} the above was adapted from:
> https://github.com/apache/lucene-solr/blob/branch_8x/solr/solr-ref-guide/build.xml#L70
>
> Beyond getting this to work, I think it's worth a discussion (separate Jira?)
> about whether we can simplify it. Maybe just a parameter
> {{ref-guide-draft=false}} would be sufficient? We might also reconsider the
> variations of versions in the Ref Guide params and whether we really need
> them ({{solr-guide-version}}, {{solr-docs-version}}).
--
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-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189075#comment-17189075 ] Uwe Schindler commented on SOLR-14579: -- Hi Erick, why did you re-apply the 8.x comments? They are as wrong as in master. If you read my explanation: Those are non-capturing lambdas so they dont prodcute instances. This is explained in Brian Goetz's technical document (from April 2012), and applies even to earliest Java 8 versions. The PR removing the static funtions in Java is correct in any Java version (8,11). > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- 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] [Comment Edited] (SOLR-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189075#comment-17189075 ] Uwe Schindler edited comment on SOLR-14579 at 9/2/20, 8:31 AM: --- Hi Erick, why did you re-apply the 8.x comments? They are as wrong as in master. If you read my explanation: Those are non-capturing lambdas so they dont produee instances. This is explained in Brian Goetz's technical document (from April 2012), and applies even to earliest Java 8 versions. The PR removing the static funtions in Java is correct in any Java version (8,11). was (Author: thetaphi): Hi Erick, why did you re-apply the 8.x comments? They are as wrong as in master. If you read my explanation: Those are non-capturing lambdas so they dont prodcute instances. This is explained in Brian Goetz's technical document (from April 2012), and applies even to earliest Java 8 versions. The PR removing the static funtions in Java is correct in any Java version (8,11). > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- 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] [Comment Edited] (SOLR-14579) Comment SolrJ 'Utils' generic map functions
[
https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188582#comment-17188582
]
Uwe Schindler edited comment on SOLR-14579 at 9/2/20, 8:33 AM:
---
Hi,
sorry the explanation by [~noble.paul] in the code is completely wrong and the
warnings can be resolved without some static methods! Please read the
specification about how lambdas are working. Lambdas are NOT converted to plain
new instances on each call (if that would be the case, tehn the whole Java
streams API would be really damn slow). It depends on the type of lambda and
what parameters it takes.
Before telling others here such completely wrong information, please read the
bytecode and understand it!
*The following information applies for any Java version supporting lambdas! (so
both 8 and 11) - the code examples and explanation below is implemented in
javac and in LambdaMetaFactory and is part of the spec.*
For the {{k -> new HashMap()}} (the "key" is String, for demonstatrion
purposes, see example below) there is exactly one instance of the functional
interface created (like in your static class). It works like this:
- The lambda does not use any variable parameter from outside. This is called a
non-capturing lambda (it captures no parameters and therefore do not need to
bind them to the functional interface class).
- Javac creates a *static* (!!!) method in the class where the lambda is
located:
{code:java}
private static HashMap lambda$somesuffix(String key) { return new HashMap(); }
{code}
- At the place of the lambda, javac inserts an invokedynamic to - indeed -
create a methodHandle that generates an anonymous class. This anonymous class
is only generated on the first call of the invokedynamic (that's the whole
trick of invokedynamic, its called bootstrapping).
- The bootstrapper returns back a methodHandle used by the caller to receive an
instance of the functional interface. And here it get's interesting: As you
see, the above method is private static and the parameters passed to it are all
coming from the lambda call, there's only exactly one instance produced. That's
because its non-capturing. IF we would use some field/variable from the outside
and pass it as parameter to the Hashmap constructor, only then it would create
a new instance on each call (capturing either "this" for then created
non-static lambda methods or a rference to the dynamic parameter).
So please fix the code and apply the patch and remove Utils.
was (Author: thetaphi):
Hi,
sorry the explanation by [~noble.paul] in the code is completely wrong and the
warnings can be resolved without some static methods! Please read the
specification about how lambdas are working. Lambdas are NOT converted to plain
new instances on each call (if that would be the case, tehn the whole Java
streams API would be really damn slow). It depends on the type of lambda and
what parameters it takes.
Before telling others here such completely wrong information, please read the
bytecode and understand it!
For the {{k -> new HashMap()}} (the "key" is String, for demonstatrion
purposes, see example below) there is exactly one instance of the functional
interface created (like in your static class). It works like this:
- The lambda does not use any variable parameter from outside. This is called a
non-capturing lambda (it captures no parameters and therefore do not need to
bind them to the functional interface class).
- Javac creates a *static* (!!!) method in the class where the lambda is
located:
{code:java}
private static HashMap lambda$somesuffix(String key) { return new HashMap(); }
{code}
- At the place of the lambda, javac inserts an invokedynamic to - indeed -
create a methodHandle that generates an anonymous class. This anonymous class
is only generated on the first call of the invokedynamic (that's the whole
trick of invokedynamic, its called bootstrapping).
- The bootstrapper returns back a methodHandle used by the caller to receive an
instance of the functional interface. And here it get's interesting: As you
see, the above method is private static and the parameters passed to it are all
coming from the lambda call, there's only exactly one instance produced. That's
because its non-capturing. IF we would use some field/variable from the outside
and pass it as parameter to the Hashmap constructor, only then it would create
a new instance on each call (capturing either "this" for then created
non-static lambda methods or a rference to the dynamic parameter).
So please fix the code and apply the patch and remove Utils.
> Comment SolrJ 'Utils' generic map functions
> ---
>
> Key: SOLR-14579
> URL: https://issues.apache.org/jira/browse/SOLR-14579
> Project: Solr
> Issue Type: Improvement
>
[jira] [Commented] (SOLR-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189078#comment-17189078 ] Uwe Schindler commented on SOLR-14579: -- Here is the Javadoc of Java 8: https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html Read sentences about "capture". > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- 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-14782) QueryElevationComponent does not handle escaped query terms
[
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189079#comment-17189079
]
Thomas Schmiereck commented on SOLR-14782:
--
For me it would be logical if the field type defined in
"{color:#067d17}queryFieldType{color}" provided a function for the unescape
which is then used automatically from the "QueryElevationComponent".
But I am not sure whether the field-type is related to the query parser that is
used.
> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
> Labels: elevation
> Attachments: SOLR-14782.patch
>
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa
> bbb"{color}><{color:#0033b3}doc
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2"
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component
> "QueryElevationComponent" does not unescape the query term bevor the lookup
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>
--
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-14579) Comment SolrJ 'Utils' generic map functions
[
https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189086#comment-17189086
]
Uwe Schindler commented on SOLR-14579:
--
If you are interested, here is the implementation of a Bootstrap for lambdas in
Elasticsearch's Painless (written by me), especially see the comment:
[LambdaBootstrap lines
126-133|https://github.com/elastic/elasticsearch/blob/0a135a358e4736ee54d76bad0932cab1b5cc1a74/modules/lang-painless/src/main/java/org/elasticsearch/painless/LambdaBootstrap.java#L126-L133]
If no captures are there: it's a singleton and the bootstrap code returns a
method handle that: [LambdaBootstrap lines
481-491|https://github.com/elastic/elasticsearch/blob/0a135a358e4736ee54d76bad0932cab1b5cc1a74/modules/lang-painless/src/main/java/org/elasticsearch/painless/LambdaBootstrap.java#L481-L491];
you see it returns a {{ConstantCallSite}} always returning the same singleton
created there with {{newInstance}}.
You can check similar code in LambdaBootstraps code in the JDK, but those are
doing a bit more magic, as Java is type-safe, while Elasticsearch Painless has
more freedom of types (e.g. def type), so this is easier to read.
> Comment SolrJ 'Utils' generic map functions
> ---
>
> Key: SOLR-14579
> URL: https://issues.apache.org/jira/browse/SOLR-14579
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Megan Carey
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.7
>
> Attachments: SOLR-14579.patch
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj
> module to reduce warnings and improve code quality.
> [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92]
--
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] [Comment Edited] (SOLR-14579) Comment SolrJ 'Utils' generic map functions
[
https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189086#comment-17189086
]
Uwe Schindler edited comment on SOLR-14579 at 9/2/20, 8:52 AM:
---
If you are interested, here is the implementation of a Bootstrap for lambdas in
Elasticsearch's Painless (written by me), especially see the comment:
[LambdaBootstrap lines
126-133|https://github.com/elastic/elasticsearch/blob/0a135a358e4736ee54d76bad0932cab1b5cc1a74/modules/lang-painless/src/main/java/org/elasticsearch/painless/LambdaBootstrap.java#L126-L133]
If no captures are there: it's a singleton and the bootstrap code returns a
call site just returning the singleton: [LambdaBootstrap lines
481-491|https://github.com/elastic/elasticsearch/blob/0a135a358e4736ee54d76bad0932cab1b5cc1a74/modules/lang-painless/src/main/java/org/elasticsearch/painless/LambdaBootstrap.java#L481-L491];
you see it returns a {{ConstantCallSite}} always returning the same singleton
using {{MethodHandles.constant()}} created there with {{newInstance}}. At a
later stage, hotspot can even inline this, so code is fast as if the lambda
won't exist at all!
You can check similar code in LambdaBootstraps code in the JDK, but those are
doing a bit more magic, as Java is type-safe, while Elasticsearch Painless has
more freedom of types (e.g. def type), so this is easier to read.
was (Author: thetaphi):
If you are interested, here is the implementation of a Bootstrap for lambdas in
Elasticsearch's Painless (written by me), especially see the comment:
[LambdaBootstrap lines
126-133|https://github.com/elastic/elasticsearch/blob/0a135a358e4736ee54d76bad0932cab1b5cc1a74/modules/lang-painless/src/main/java/org/elasticsearch/painless/LambdaBootstrap.java#L126-L133]
If no captures are there: it's a singleton and the bootstrap code returns a
method handle that: [LambdaBootstrap lines
481-491|https://github.com/elastic/elasticsearch/blob/0a135a358e4736ee54d76bad0932cab1b5cc1a74/modules/lang-painless/src/main/java/org/elasticsearch/painless/LambdaBootstrap.java#L481-L491];
you see it returns a {{ConstantCallSite}} always returning the same singleton
created there with {{newInstance}}.
You can check similar code in LambdaBootstraps code in the JDK, but those are
doing a bit more magic, as Java is type-safe, while Elasticsearch Painless has
more freedom of types (e.g. def type), so this is easier to read.
> Comment SolrJ 'Utils' generic map functions
> ---
>
> Key: SOLR-14579
> URL: https://issues.apache.org/jira/browse/SOLR-14579
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Megan Carey
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.7
>
> Attachments: SOLR-14579.patch
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj
> module to reduce warnings and improve code quality.
> [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92]
--
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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189087#comment-17189087 ] Colvin Cowie commented on SOLR-14422: - This didn't make it into the 8.6 release, it's only been pushed to master [~broustant] [~epugh] > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.6 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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-9496) Replace (or accelerate) check-broken-links.gradle with a doclet pass
[ https://issues.apache.org/jira/browse/LUCENE-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189090#comment-17189090 ] Dawid Weiss commented on LUCENE-9496: - Somehow I knew you'd be interested. :) Playing with those compilation trees is a lot of fun. It isn't exactly easy too so it's not a trivial effort but I have a feeling it can be done. > Replace (or accelerate) check-broken-links.gradle with a doclet pass > > > Key: LUCENE-9496 > URL: https://issues.apache.org/jira/browse/LUCENE-9496 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This is just a placeholder, but perhaps somebody will find the time to push > this forward. The current python script in check-broken-links reparses all > emitted HTML files to find links. I have a strong feeling this could be done > better. > Javadoc doclets have access to parse trees for both the code and the javadoc > comments (including information about HTML tags, code links, etc.). For > example, this information is used by the built-in javac HTML linter. > Maybe we could replace the python linter entirely; verify where code links > will point at, where existing HTML links point to and validate this > information. I wrote some of that link-parsing code in Carrot2 (to convert > javadocs into a structured JSON format used in other documentation). The code > there is free to eyeball and borrow, if needed. > https://docs.oracle.com/en/java/javase/11/docs/api/jdk.compiler/com/sun/source/util/DocTreeScanner.html > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/JavaDocsVisitor.java#L135 > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/PlainReferenceConverter.java -- 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-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189094#comment-17189094 ] Uwe Schindler commented on SOLR-14579: -- Here is the similar code in Java 8: [InnerClassLambdaMetafactory line 215|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#l215] It's returning a static singleton, because no arguments are captured (which is waht we talk about here), the code below is the captured lambda which has the overhead (see the presentation by [~ichattopadhyaya] mentioned in Slack: [https://www.oracle.com/technetwork/java/jvmls2013kuksen-2014088.pdf]). > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- 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-9438) Add gradle workflow support for Eclipse IDE
[
https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189096#comment-17189096
]
Adrien Grand commented on LUCENE-9438:
--
This worked well for me to get the project to compile, but running tests
doesn't work as resources are not on the classpath, so codecs are not loaded. I
had to do the following to make it work
{code}
diff --git a/gradle/ide/eclipse.gradle b/gradle/ide/eclipse.gradle
index e414112697a..12e1bdc95a6 100644
--- a/gradle/ide/eclipse.gradle
+++ b/gradle/ide/eclipse.gradle
@@ -47,6 +47,7 @@ configure(rootProject) {
projects.each { prj ->
prj.sourceSets.each { sourceSet ->
sources += sourceSet.java.srcDirs.findAll { dir -> dir.exists()
}.collect { dir -> relativize(dir) }
+ sources += sourceSet.resources.srcDirs.findAll { dir ->
dir.exists() }.collect { dir -> relativize(dir) }
}
// This is hacky - we take the resolved compile classpath and just
{code}
This might not be the best way to do this as I have very little Groovy/Gradle
knowledge.
> Add gradle workflow support for Eclipse IDE
> ---
>
> Key: LUCENE-9438
> URL: https://issues.apache.org/jira/browse/LUCENE-9438
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: capture-1.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Off the top of my head I've tried using the eclipse plugin (this should
> prepare "static" classpath entries pointing at local gradle caches). It
> almost works... almost because we have references between sub-atomic project
> elements (tests and main) that make Eclipse see these as circular (because
> Eclipse treats project sources and main classes as one).
> I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it
> work. I'm not a big fan of having a single "blob" project with all the
> sources and classpaths combined (the IDE won't help you figure out what's
> accessible from a given subproject then) but maybe it's the only way to make
> it work for Eclipse, don't know.
--
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-14782) QueryElevationComponent does not handle escaped query terms
[
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189098#comment-17189098
]
Bruno Roustant commented on SOLR-14782:
---
[~smk] you should add a CharFilter to unescape for query elevation. Instead of
using lowercase for the queryFieldType you could use unescapelowercase with the
following definition:
{code:java}
{code}
[~dsmiley] this regex pattern replacement CharFilter is not easy. Should we
have a new simpler and equivalent UnescapeCharFilterFactory? In any case I
think it would be nice to add a paragraph to explain that in the
QueryElevationComponent doc.
> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
> Labels: elevation
> Attachments: SOLR-14782.patch
>
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa
> bbb"{color}><{color:#0033b3}doc
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2"
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component
> "QueryElevationComponent" does not unescape the query term bevor the lookup
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>
--
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] [Comment Edited] (SOLR-14782) QueryElevationComponent does not handle escaped query terms
[
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189098#comment-17189098
]
Bruno Roustant edited comment on SOLR-14782 at 9/2/20, 9:17 AM:
[~smk] you should add a CharFilter to unescape for query elevation. Instead of
using lowercase for the queryFieldType you could use unescapelowercase with the
following definition:
{code:java}
{code}
[~dsmiley] this regex pattern replacement CharFilter is not easy. Should we
have a new simpler and equivalent UnescapeCharFilterFactory? In any case I
think it would be nice to add a paragraph to explain that in the
QueryElevationComponent doc.
was (Author: broustant):
[~smk] you should add a CharFilter to unescape for query elevation. Instead of
using lowercase for the queryFieldType you could use unescapelowercase with the
following definition:
{code:java}
{code}
[~dsmiley] this regex pattern replacement CharFilter is not easy. Should we
have a new simpler and equivalent UnescapeCharFilterFactory? In any case I
think it would be nice to add a paragraph to explain that in the
QueryElevationComponent doc.
> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
> Labels: elevation
> Attachments: SOLR-14782.patch
>
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa
> bbb"{color}><{color:#0033b3}doc
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2"
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component
> "QueryElevationComponent" does not unescape the query term bevor the lookup
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>
--
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] bruno-roustant opened a new pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant opened a new pull request #1819: URL: https://github.com/apache/lucene-solr/pull/1819 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-14782) QueryElevationComponent does not handle escaped query terms
[
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189123#comment-17189123
]
Bruno Roustant commented on SOLR-14782:
---
I added a PR for the doc improvement. I think it will be sufficient (no need
for an UnescapeCharFilterFactory).
Thomas, you should use a StandardTokenizerFactory because with 8.3 it becomes
possible to match a subset of the query terms (not always a full match
anymore), see SOLR-11866. If you use a KeywordTokenizerFactory, it produces
only the full query as a single token, so no subset matching possible.
> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
> Labels: elevation
> Attachments: SOLR-14782.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa
> bbb"{color}><{color:#0033b3}doc
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2"
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component
> "QueryElevationComponent" does not unescape the query term bevor the lookup
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>
--
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-9438) Add gradle workflow support for Eclipse IDE
[ https://issues.apache.org/jira/browse/LUCENE-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189124#comment-17189124 ] Dawid Weiss commented on LUCENE-9438: - This is correct, Adrien. Please commit it in! Separately from this, I'd really recommend trying IntelliJ IDEA as its support for classpath resolution and scopes is much superior to Eclipse's. > Add gradle workflow support for Eclipse IDE > --- > > Key: LUCENE-9438 > URL: https://issues.apache.org/jira/browse/LUCENE-9438 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Attachments: capture-1.png > > Time Spent: 20m > Remaining Estimate: 0h > > Off the top of my head I've tried using the eclipse plugin (this should > prepare "static" classpath entries pointing at local gradle caches). It > almost works... almost because we have references between sub-atomic project > elements (tests and main) that make Eclipse see these as circular (because > Eclipse treats project sources and main classes as one). > I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it > work. I'm not a big fan of having a single "blob" project with all the > sources and classpaths combined (the IDE won't help you figure out what's > accessible from a given subproject then) but maybe it's the only way to make > it work for Eclipse, don't know. -- 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] jpountz commented on a change in pull request #1789: LUCENE-9484: Allow sorting an index after the fact
jpountz commented on a change in pull request #1789:
URL: https://github.com/apache/lucene-solr/pull/1789#discussion_r481823967
##
File path:
lucene/core/src/java/org/apache/lucene/index/BinaryDocValuesWriter.java
##
@@ -202,4 +203,63 @@ public BytesRef binaryValue() {
return value.get();
}
}
+
+ static class SortingBinaryDocValues extends BinaryDocValues {
+
+private final CachedBinaryDVs dvs;
+private int docID = -1;
+
+SortingBinaryDocValues(CachedBinaryDVs dvs) {
+ this.dvs = dvs;
+}
+
+@Override
+public int nextDoc() {
+ if (docID+1 == dvs.docsWithField.length()) {
+docID = NO_MORE_DOCS;
+ } else {
+docID = dvs.docsWithField.nextSetBit(docID+1);
+ }
+
+ return docID;
+}
+
+@Override
+public int docID() {
+ return docID;
+}
+
+@Override
+public int advance(int target) {
+ docID = dvs.docsWithField.nextSetBit(target);
+ return docID;
+}
+
+@Override
+public boolean advanceExact(int target) throws IOException {
+ docID = target;
+ return dvs.docsWithField.get(target);
+}
+
+@Override
+public BytesRef binaryValue() {
+ return dvs.values[docID];
+}
+
+@Override
+public long cost() {
+ return dvs.docsWithField.cardinality();
Review comment:
I think we should either throw UOE here or cache the cardinality.
##
File path:
lucene/core/src/java/org/apache/lucene/index/BinaryDocValuesWriter.java
##
@@ -202,4 +203,63 @@ public BytesRef binaryValue() {
return value.get();
}
}
+
+ static class SortingBinaryDocValues extends BinaryDocValues {
+
+private final CachedBinaryDVs dvs;
+private int docID = -1;
+
+SortingBinaryDocValues(CachedBinaryDVs dvs) {
+ this.dvs = dvs;
+}
+
+@Override
+public int nextDoc() {
+ if (docID+1 == dvs.docsWithField.length()) {
+docID = NO_MORE_DOCS;
+ } else {
+docID = dvs.docsWithField.nextSetBit(docID+1);
+ }
+
+ return docID;
+}
+
+@Override
+public int docID() {
+ return docID;
+}
+
+@Override
+public int advance(int target) {
+ docID = dvs.docsWithField.nextSetBit(target);
+ return docID;
Review comment:
I think this will fail if target is > maxDoc? Maybe this class should
just throw UOE for advance and advanceExact since codecs are only supposed to
consume these doc values via nextDoc.
##
File path: lucene/core/src/java/org/apache/lucene/index/SortingCodecReader.java
##
@@ -0,0 +1,514 @@
+/*
+ * 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 java.util.Arrays;
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.Map;
+
+import org.apache.lucene.codecs.DocValuesProducer;
+import org.apache.lucene.codecs.FieldsProducer;
+import org.apache.lucene.codecs.NormsProducer;
+import org.apache.lucene.codecs.PointsReader;
+import org.apache.lucene.codecs.StoredFieldsReader;
+import org.apache.lucene.codecs.TermVectorsReader;
+import org.apache.lucene.search.Sort;
+import org.apache.lucene.util.Bits;
+import org.apache.lucene.util.FixedBitSet;
+
+import static org.apache.lucene.search.DocIdSetIterator.NO_MORE_DOCS;
+
+/**
+ * An {@link org.apache.lucene.index.CodecReader} which supports sorting
documents by a given
+ * {@link Sort}. This can be used to re-sort and index after it's been created
by wrapping all
+ * readers of the index with this reader and adding it to a fresh IndexWriter
via
+ * {@link IndexWriter#addIndexes(CodecReader...)}.
+ *
+ * @lucene.experimental
+ */
+public final class SortingCodecReader extends FilterCodecReader {
+
+ private final Map
cachedNumericDVs = new HashMap<>();
+
+ private final Map
cachedBinaryDVs = new HashMap<>();
+
+ private final Map cachedSortedDVs = new HashMap<>();
+
+ // TODO: pack long[][] into an int[] (offset) and long[] instead:
+ private final Map cachedSortedSetDVs = new HashMap<>();
+
+ private final Map cachedSortedNumericDVs = new HashMap<>();
+
+ private static class SortingBits implements Bits {
+
+private final Bits i
[GitHub] [lucene-solr] dweiss opened a new pull request #1820: LUCENE-9464: Add high(er)-level hit highlighter example that demonstrates and uses low-level components
dweiss opened a new pull request #1820: URL: https://github.com/apache/lucene-solr/pull/1820 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-9464) Add high(er)-level hit highlighter example that demonstrates and uses low-level components
[ https://issues.apache.org/jira/browse/LUCENE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189136#comment-17189136 ] Dawid Weiss commented on LUCENE-9464: - Hi Alan ([~romseygeek]). Finally got down to writing something that would be end-user usable and would at the same time showcase those match highlighter components. I didn't want to make the "MatchHighlighter" too simple because then it wouldn't show all the advantages of using this code. I also didn't want to make it too complex because it's not the point (if you need something really complex, you'd use those low-level components directly rather than jump through hoops to make the high-level highlighter work for you). Please feel free to review when you have time. I think the best start would be test [1], which takes you step-by-step trough various scenarios. Let me know what you think. [1] https://github.com/dweiss/lucene-solr/blob/LUCENE-9464/lucene/highlighter/src/test/org/apache/lucene/search/matchhighlight/TestMatchHighlighter.java#L118-L400 > Add high(er)-level hit highlighter example that demonstrates and uses > low-level components > -- > > Key: LUCENE-9464 > URL: https://issues.apache.org/jira/browse/LUCENE-9464 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- 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-14821) docValuesTermsFilter should support single-valued docValues fields
Anatolii Siuniaev created SOLR-14821: Summary: docValuesTermsFilter should support single-valued docValues fields Key: SOLR-14821 URL: https://issues.apache.org/jira/browse/SOLR-14821 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: query parsers Reporter: Anatolii Siuniaev https://issues.apache.org/jira/browse/SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter in TermsQParserPlugin. But now it supports only multi-valued docValues fields (i.e. SORTED_SET type DocValues) It doesn't work for single-valued docValues fields (i.e. SORTED type DocValues), though it should. -- 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] (LUCENE-9498) Move matchhighlighter to a separate subproject
Dawid Weiss created LUCENE-9498:
---
Summary: Move matchhighlighter to a separate subproject
Key: LUCENE-9498
URL: https://issues.apache.org/jira/browse/LUCENE-9498
Project: Lucene - Core
Issue Type: Sub-task
Reporter: Dawid Weiss
Assignee: Dawid Weiss
This is a trivial thing to do (on master at least). Match highlighter has no
other dependencies. It sort of fits in the "highlighter" package but this
package depends on {{queries}} and {{memory}} packages. I wonder if we should
move it to a separate subproject?
--
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-9495) Ref Guide gradle buildSite ignores version parameter
[
https://issues.apache.org/jira/browse/LUCENE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189149#comment-17189149
]
Dawid Weiss commented on LUCENE-9495:
-
I changed the build script to accept -P or -D for solrGuideVersion. Hoss -- you
absolutely should use the provided wrapper script, not your system's gradle.
{code}
hossman@slate:~/lucene/dev/solr/solr-ref-guide [j11] [master] $ gradle
buildSite -PsolrGuideVersion=9.0
{code}
This is important as those startup shell scripts in the repo have additional
stuff added on top of them compared to stock gradle.
> Ref Guide gradle buildSite ignores version parameter
>
>
> Key: LUCENE-9495
> URL: https://issues.apache.org/jira/browse/LUCENE-9495
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Reporter: Cassandra Targett
>Priority: Major
>
> All Ref Guide builds by default are built as drafts. A DRAFT watermark is
> inserted on to every page, a special header is added to the side navigation,
> and the footer version includes the word "-DRAFT".
> To accomplish this, the guide has long used a parameter
> {{solr-guide-version}} to indicate when a build for the Ref Guide _should
> not_ be considered a draft. With the Gradle build, this no longer works. (I
> thought I'd tested this, but either I missed it or it broke at some point in
> between.)
> [~hossman] set this up several years ago, so cc'ing him here so he can take a
> look and see why the logic would stop working now.
> Links:
> Ref Guide {{build.gradle}} that determines Guide version:
> https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/build.gradle#L128
> Ant {{build.xml}} the above was adapted from:
> https://github.com/apache/lucene-solr/blob/branch_8x/solr/solr-ref-guide/build.xml#L70
>
> Beyond getting this to work, I think it's worth a discussion (separate Jira?)
> about whether we can simplify it. Maybe just a parameter
> {{ref-guide-draft=false}} would be sufficient? We might also reconsider the
> variations of versions in the Ref Guide params and whether we really need
> them ({{solr-guide-version}}, {{solr-docs-version}}).
--
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 #1821: SOLR-14822: Gradle: solr ref guide's dependencies should be moved to the test pool (palantir)
dweiss opened a new pull request #1821: URL: https://github.com/apache/lucene-solr/pull/1821 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] [Created] (SOLR-14822) Gradle: solr ref guide's dependencies should be moved to the test pool (palantir)
Dawid Weiss created SOLR-14822: -- Summary: Gradle: solr ref guide's dependencies should be moved to the test pool (palantir) Key: SOLR-14822 URL: https://issues.apache.org/jira/browse/SOLR-14822 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Dawid Weiss Assignee: Dawid Weiss -- 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh updated SOLR-14422: --- Status: Reopened (was: Closed) > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.6 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh updated SOLR-14422: --- Fix Version/s: (was: 8.6) 8.7 Affects Version/s: 8.6 8.6.2 > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189160#comment-17189160 ] ASF subversion and git services commented on SOLR-14422: Commit 6ab3660f25b8ea38928373b313512190f1c42f93 in lucene-solr's branch refs/heads/master from epugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6ab3660 ] SOLR-14422 was committed to master but not documented > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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 merged pull request #1821: SOLR-14822: Gradle: solr ref guide's dependencies should be moved to the test pool (palantir)
dweiss merged pull request #1821: URL: https://github.com/apache/lucene-solr/pull/1821 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-14822) Gradle: solr ref guide's dependencies should be moved to the test pool (palantir)
[ https://issues.apache.org/jira/browse/SOLR-14822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189162#comment-17189162 ] ASF subversion and git services commented on SOLR-14822: Commit defffd40cbbca28131b2b9881efb45f155c6309b in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=defffd4 ] SOLR-14822: Gradle: solr ref guide's dependencies should be moved to the test pool (palantir) (#1821) > Gradle: solr ref guide's dependencies should be moved to the test pool > (palantir) > - > > Key: SOLR-14822 > URL: https://issues.apache.org/jira/browse/SOLR-14822 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > -- 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-14822) Gradle: solr ref guide's dependencies should be moved to the test pool (palantir)
[ https://issues.apache.org/jira/browse/SOLR-14822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-14822. Fix Version/s: master (9.0) Resolution: Fixed > Gradle: solr ref guide's dependencies should be moved to the test pool > (palantir) > - > > Key: SOLR-14822 > URL: https://issues.apache.org/jira/browse/SOLR-14822 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > -- 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189165#comment-17189165 ] David Eric Pugh commented on SOLR-14422: Thanks [~cjcowie]for sharp eyes. This was when I just joined the project as a committer, and was (and am still!) figuring out things. 45573b9f1dbbc5bb46ca27a04ed5cf240c6da3b0 is the commit hash for the original fix, and 6ab3660f25b8ea38928373b313512190f1c42f93 adds it to the Changes.txt on master. I am working on what the best way to bring it to branch_8x... > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh resolved SOLR-14422. Now pushed to branch_8x > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189166#comment-17189166 ] ASF subversion and git services commented on SOLR-14422: Commit 34683c5df9629289b169005282f1bda3df1b2453 in lucene-solr's branch refs/heads/branch_8x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=34683c5 ] SOLR-14422 progressive render load main admin page (#1654) * hide error message template until angular app has loaded > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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-9215) replace checkJavaDocs.py with doclet
[
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189187#comment-17189187
]
ASF subversion and git services commented on LUCENE-9215:
-
Commit ba4fbcdac1d551fd8b09d11d6e91d1cd145c0caa in lucene-solr's branch
refs/heads/LUCENE-9215 from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ba4fbcd ]
LUCENE-9215: add missing javadocs and reset visibility
> replace checkJavaDocs.py with doclet
>
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when
> newer java change html output. This is not particularly fun to fix: see
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class
> across 11,12,13 it surprised me how much changes. So I think we want to avoid
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white.
> Either everything is fully documented or its not. And while you can
> enable/disable doclint checks per-package, this also seems black/white
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at
> different granularities (package, class, method). It makes it possible to
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match
> checkJavaDocs.py logic:
> {code}
> private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
> error(element, "javadocs are missing");
> } else {
> var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
> if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
> } else if (normalized.startsWith("licensed to the apache software
> foundation") ||
> normalized.startsWith("copyright 2004 the apache software
> foundation")) {
> error(element, "comment is really a license");
> }
> }
> {code}
> If there are problems then they just appear as errors from the output of
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
> error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
> error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
> error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
> error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
> error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
> error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
> error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
> error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
> error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
> error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
> error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
> error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
> error - LicenseDoc (class): comment is real
[GitHub] [lucene-solr] rmuir commented on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet
rmuir commented on pull request #1802: URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-685687970 I've added missing javadocs and reset visibility for the remaining classes, with one or two exceptions (and if you look at those, its clear the visibility was straight up wrong, because nothing else in the class (fields, methods) is visible. Frankly, If we want to get this in and remove the python, now is the time I think. Otherwise let's decide we really like the python because that goddamn thing has been *way* too hard to get rid of. I'm just simply not going to be able to keep up with the new changes in master due to time constraints. 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 merged pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet
rmuir merged pull request #1802: URL: https://github.com/apache/lucene-solr/pull/1802 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-9215) replace checkJavaDocs.py with doclet
[
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189202#comment-17189202
]
ASF subversion and git services commented on LUCENE-9215:
-
Commit 784ede4eda911416bac0912c077380b59df8b988 in lucene-solr's branch
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=784ede4 ]
LUCENE-9215: replace checkJavaDocs.py with doclet (#1802)
This has the same logic as the previous python, but no longer relies
upon parsing HTML output, instead using java's doclet processor.
The errors are reported like "normal" javadoc errors with source file
name and line number and happen when running "gradlew javadoc"
Although the "rules" are the same as the previous python, the python had
some bugs where the checker didn't quite do exactly what we wanted, so
some fixes were applied throughout.
Co-authored-by: Dawid Weiss
Co-authored-by: Uwe Schindler
> replace checkJavaDocs.py with doclet
>
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when
> newer java change html output. This is not particularly fun to fix: see
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class
> across 11,12,13 it surprised me how much changes. So I think we want to avoid
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white.
> Either everything is fully documented or its not. And while you can
> enable/disable doclint checks per-package, this also seems black/white
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at
> different granularities (package, class, method). It makes it possible to
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match
> checkJavaDocs.py logic:
> {code}
> private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
> error(element, "javadocs are missing");
> } else {
> var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
> if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
> } else if (normalized.startsWith("licensed to the apache software
> foundation") ||
> normalized.startsWith("copyright 2004 the apache software
> foundation")) {
> error(element, "comment is really a license");
> }
> }
> {code}
> If there are problems then they just appear as errors from the output of
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
> error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
> error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
> error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
> error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
> error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
> error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
> error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
> error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
> error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
> error - Pag
[jira] [Commented] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189203#comment-17189203 ] ASF subversion and git services commented on SOLR-14422: Commit ed32e22c9f7a5848149bb24817c7d71b54025f76 in lucene-solr's branch refs/heads/branch_8x from epugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ed32e22 ] document that SOLR-14422 is finally backported to 8x > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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-9215) replace checkJavaDocs.py with doclet
[
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189201#comment-17189201
]
ASF subversion and git services commented on LUCENE-9215:
-
Commit 784ede4eda911416bac0912c077380b59df8b988 in lucene-solr's branch
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=784ede4 ]
LUCENE-9215: replace checkJavaDocs.py with doclet (#1802)
This has the same logic as the previous python, but no longer relies
upon parsing HTML output, instead using java's doclet processor.
The errors are reported like "normal" javadoc errors with source file
name and line number and happen when running "gradlew javadoc"
Although the "rules" are the same as the previous python, the python had
some bugs where the checker didn't quite do exactly what we wanted, so
some fixes were applied throughout.
Co-authored-by: Dawid Weiss
Co-authored-by: Uwe Schindler
> replace checkJavaDocs.py with doclet
>
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when
> newer java change html output. This is not particularly fun to fix: see
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class
> across 11,12,13 it surprised me how much changes. So I think we want to avoid
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white.
> Either everything is fully documented or its not. And while you can
> enable/disable doclint checks per-package, this also seems black/white
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at
> different granularities (package, class, method). It makes it possible to
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match
> checkJavaDocs.py logic:
> {code}
> private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
> error(element, "javadocs are missing");
> } else {
> var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
> if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
> } else if (normalized.startsWith("licensed to the apache software
> foundation") ||
> normalized.startsWith("copyright 2004 the apache software
> foundation")) {
> error(element, "comment is really a license");
> }
> }
> {code}
> If there are problems then they just appear as errors from the output of
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
> error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
> error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
> error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
> error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
> error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
> error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
> error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
> error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
> error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
> error - Pag
[jira] [Resolved] (LUCENE-9215) replace checkJavaDocs.py with doclet
[
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-9215.
-
Fix Version/s: master (9.0)
Assignee: Robert Muir
Resolution: Fixed
Thank you [~uschindler] [~dweiss] [~tomoko]. Finally the battle is over :)
Hopefully we don't have hassles on new JDK versions anymore (or at least they
are less annoying to fix).
> replace checkJavaDocs.py with doclet
>
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when
> newer java change html output. This is not particularly fun to fix: see
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class
> across 11,12,13 it surprised me how much changes. So I think we want to avoid
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white.
> Either everything is fully documented or its not. And while you can
> enable/disable doclint checks per-package, this also seems black/white
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at
> different granularities (package, class, method). It makes it possible to
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match
> checkJavaDocs.py logic:
> {code}
> private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
> error(element, "javadocs are missing");
> } else {
> var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
> if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
> } else if (normalized.startsWith("licensed to the apache software
> foundation") ||
> normalized.startsWith("copyright 2004 the apache software
> foundation")) {
> error(element, "comment is really a license");
> }
> }
> {code}
> If there are problems then they just appear as errors from the output of
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
> error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
> error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
> error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
> error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
> error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
> error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
> error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
> error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
> error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
> error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
> error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
> error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
> error - LicenseDoc (class): comment
[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #1818: SOLR-14819 Trivial fix to inefficient iterator pattern
bruno-roustant commented on a change in pull request #1818:
URL: https://github.com/apache/lucene-solr/pull/1818#discussion_r482036367
##
File path:
solr/solrj/src/java/org/apache/solr/common/util/JsonSchemaValidator.java
##
@@ -48,13 +48,15 @@ public JsonSchemaValidator(String jsonString) {
public JsonSchemaValidator(Map jsonSchema) {
this.validators = new LinkedList<>();
-for (Object fname : jsonSchema.keySet()) {
+for (Object entry : jsonSchema.entrySet()) {
Review comment:
+1 (same for the other loop below)
##
File path: .muse.toml
##
@@ -0,0 +1 @@
+jdk11 = true
Review comment:
Please remove this from the PR
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-14819) SOLR has linear log operations that could trivially be linear
[ https://issues.apache.org/jira/browse/SOLR-14819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189211#comment-17189211 ] Bruno Roustant commented on SOLR-14819: --- [~tommd] was there other issues found by Infer on Muse? > SOLR has linear log operations that could trivially be linear > - > > Key: SOLR-14819 > URL: https://issues.apache.org/jira/browse/SOLR-14819 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Thomas DuBuisson >Priority: Trivial > Time Spent: 0.5h > Remaining Estimate: 0h > > The SOLR code has a few linear log operations that could be linear. That is, > operations of > > ``` > for(key in hashmap) doThing(hashmap.get(key)); > > ``` > > vs just `for(value in hashmap) doThing(value)` > > I have a PR incoming on GitHub to fix a couple of these issue as [found by > Infer on > Muse|https://console.muse.dev/result/TomMD/lucene-solr/01EH5WXS6C1RH1NFYHP6ATXTZ9?search=JsonSchemaValidator&tab=results]. > -- 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-9496) Replace (or accelerate) check-broken-links.gradle with a doclet pass
[ https://issues.apache.org/jira/browse/LUCENE-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189214#comment-17189214 ] Robert Muir commented on LUCENE-9496: - It looks like the doc tree will give you a "Link" node that has a "Reference" (basically just the signature of what we're linking to). Ideally we would just "check" that each reference is "included": but i'm not sure if it can be that simple: as some of the links might go across JARs. Otherwise another alternative is to explicitly implement logic to check for reasons why the link would be broken: e.g. that the signature refers to something with private/package-private scope. It is worth considering because we could probably give very explicit nice error messages to the developer rather than just a "broken link" error. Today the errors might be non-intuitive when you do such a thing. Third option would be to just parse the HTML output with SAX or something, if we want it to be java or groovy instead of python. But this wouldn't be any "better" (error messaging, speed, wrestling with bugs in javadoc generation itself, etc), but it would at least get the precommit to pure java. > Replace (or accelerate) check-broken-links.gradle with a doclet pass > > > Key: LUCENE-9496 > URL: https://issues.apache.org/jira/browse/LUCENE-9496 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This is just a placeholder, but perhaps somebody will find the time to push > this forward. The current python script in check-broken-links reparses all > emitted HTML files to find links. I have a strong feeling this could be done > better. > Javadoc doclets have access to parse trees for both the code and the javadoc > comments (including information about HTML tags, code links, etc.). For > example, this information is used by the built-in javac HTML linter. > Maybe we could replace the python linter entirely; verify where code links > will point at, where existing HTML links point to and validate this > information. I wrote some of that link-parsing code in Carrot2 (to convert > javadocs into a structured JSON format used in other documentation). The code > there is free to eyeball and borrow, if needed. > https://docs.oracle.com/en/java/javase/11/docs/api/jdk.compiler/com/sun/source/util/DocTreeScanner.html > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/JavaDocsVisitor.java#L135 > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/PlainReferenceConverter.java -- 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-14821) docValuesTermsFilter should support single-valued docValues fields
[ https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-14821: Description: SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter in TermsQParserPlugin. But now it supports only multi-valued docValues fields (i.e. SORTED_SET type DocValues) It doesn't work for single-valued docValues fields (i.e. SORTED type DocValues), though it should. was: https://issues.apache.org/jira/browse/SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter in TermsQParserPlugin. But now it supports only multi-valued docValues fields (i.e. SORTED_SET type DocValues) It doesn't work for single-valued docValues fields (i.e. SORTED type DocValues), though it should. > docValuesTermsFilter should support single-valued docValues fields > -- > > Key: SOLR-14821 > URL: https://issues.apache.org/jira/browse/SOLR-14821 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Anatolii Siuniaev >Priority: Minor > > SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter > in TermsQParserPlugin. But now it supports only multi-valued docValues > fields (i.e. SORTED_SET type DocValues) > It doesn't work for single-valued docValues fields (i.e. SORTED type > DocValues), though it should. -- 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-14821) docValuesTermsFilter should support single-valued docValues fields
[ https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anatolii Siuniaev updated SOLR-14821: - Attachment: SOLR-14821.patch > docValuesTermsFilter should support single-valued docValues fields > -- > > Key: SOLR-14821 > URL: https://issues.apache.org/jira/browse/SOLR-14821 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Anatolii Siuniaev >Priority: Minor > Attachments: SOLR-14821.patch > > > SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter > in TermsQParserPlugin. But now it supports only multi-valued docValues > fields (i.e. SORTED_SET type DocValues) > It doesn't work for single-valued docValues fields (i.e. SORTED type > DocValues), though it should. -- 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-14821) docValuesTermsFilter should support single-valued docValues fields
[ https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189242#comment-17189242 ] Anatolii Siuniaev commented on SOLR-14821: -- This is a single line fix for SORTED type docValues - just add a method wrapping SortedDocValues into SortedSetDocValues. [^SOLR-14821.patch] > docValuesTermsFilter should support single-valued docValues fields > -- > > Key: SOLR-14821 > URL: https://issues.apache.org/jira/browse/SOLR-14821 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Anatolii Siuniaev >Priority: Minor > Attachments: SOLR-14821.patch > > > SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter > in TermsQParserPlugin. But now it supports only multi-valued docValues > fields (i.e. SORTED_SET type DocValues) > It doesn't work for single-valued docValues fields (i.e. SORTED type > DocValues), though it should. -- 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] [Comment Edited] (SOLR-14821) docValuesTermsFilter should support single-valued docValues fields
[ https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189242#comment-17189242 ] Anatolii Siuniaev edited comment on SOLR-14821 at 9/2/20, 1:42 PM: --- This is a single line fix for SORTED type docValues - just added a method wrapping SortedDocValues into SortedSetDocValues. [^SOLR-14821.patch] was (Author: anatolii_siuniaev): This is a single line fix for SORTED type docValues - just add a method wrapping SortedDocValues into SortedSetDocValues. [^SOLR-14821.patch] > docValuesTermsFilter should support single-valued docValues fields > -- > > Key: SOLR-14821 > URL: https://issues.apache.org/jira/browse/SOLR-14821 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Anatolii Siuniaev >Priority: Minor > Attachments: SOLR-14821.patch > > > SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter > in TermsQParserPlugin. But now it supports only multi-valued docValues > fields (i.e. SORTED_SET type DocValues) > It doesn't work for single-valued docValues fields (i.e. SORTED type > DocValues), though it should. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14821) docValuesTermsFilter should support single-valued docValues fields
[ https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski reassigned SOLR-14821: -- Assignee: Jason Gerlowski > docValuesTermsFilter should support single-valued docValues fields > -- > > Key: SOLR-14821 > URL: https://issues.apache.org/jira/browse/SOLR-14821 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Anatolii Siuniaev >Assignee: Jason Gerlowski >Priority: Minor > Attachments: SOLR-14821.patch > > > SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter > in TermsQParserPlugin. But now it supports only multi-valued docValues > fields (i.e. SORTED_SET type DocValues) > It doesn't work for single-valued docValues fields (i.e. SORTED type > DocValues), though it should. -- 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-14821) docValuesTermsFilter should support single-valued docValues fields
[ https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189243#comment-17189243 ] Jason Gerlowski commented on SOLR-14821: Hi Anatolii, thanks for filing the bug and attaching a fix. I'm a little surprised by this as I thought we had tests for this case, but maybe they're not doing what I'd intended? In any case I've assigned this to myself and will take a look shortly. Thanks for getting the ball rolling. > docValuesTermsFilter should support single-valued docValues fields > -- > > Key: SOLR-14821 > URL: https://issues.apache.org/jira/browse/SOLR-14821 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Reporter: Anatolii Siuniaev >Assignee: Jason Gerlowski >Priority: Minor > Attachments: SOLR-14821.patch > > > SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter > in TermsQParserPlugin. But now it supports only multi-valued docValues > fields (i.e. SORTED_SET type DocValues) > It doesn't work for single-valued docValues fields (i.e. SORTED type > DocValues), though it should. -- 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-9724) excludeTags support in conjunction with facet domain changes
[ https://issues.apache.org/jira/browse/SOLR-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189247#comment-17189247 ] Michael Gibney commented on SOLR-9724: -- I believe there's a fix for this issue, as side-effect of work on SOLR-13807 (facet term count cache, which requires tracking the queries that define FacetContext domain). The relevant part of the code from PR #1357 is [here|https://github.com/apache/lucene-solr/pull/1357/files#diff-35a3af2f5482d7a5d251ceacb25d4d5dR224-R239]. > excludeTags support in conjunction with facet domain changes > > > Key: SOLR-9724 > URL: https://issues.apache.org/jira/browse/SOLR-9724 > Project: Solr > Issue Type: Improvement > Components: Facet Module >Reporter: Yonik Seeley >Priority: Major > > Currently excludeTags only works when there are no explicit facet domain > change operations in a parent facet. Only the implicit constraint/filter > caused by the facet bucket itself is handled. -- 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-14823) Allow Rule Based Replica Policy
Mark Robert Miller created SOLR-14823: - Summary: Allow Rule Based Replica Policy Key: SOLR-14823 URL: https://issues.apache.org/jira/browse/SOLR-14823 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Mark Robert Miller When I disabled the slow replica placement, at the time I also just skipped the rule based policy - this should be allowed and those tests reenabled. -- 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-14823) Allow Rule Based Replica Assignment Policy
[ https://issues.apache.org/jira/browse/SOLR-14823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Robert Miller updated SOLR-14823: -- Summary: Allow Rule Based Replica Assignment Policy (was: Allow Rule Based Replica Policy) > Allow Rule Based Replica Assignment Policy > -- > > Key: SOLR-14823 > URL: https://issues.apache.org/jira/browse/SOLR-14823 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Robert Miller >Priority: Major > > When I disabled the slow replica placement, at the time I also just skipped > the rule based policy - this should be allowed and those tests reenabled. -- 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-8985) SynonymGraphFilter cannot handle input stream with tokens filtered.
[ https://issues.apache.org/jira/browse/LUCENE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189264#comment-17189264 ] Jan Høydahl commented on LUCENE-8985: - Any thoughts on the way forward for this? > SynonymGraphFilter cannot handle input stream with tokens filtered. > --- > > Key: LUCENE-8985 > URL: https://issues.apache.org/jira/browse/LUCENE-8985 > Project: Lucene - Core > Issue Type: Bug >Reporter: Chongchen Chen >Priority: Major > Fix For: 8.3 > > Attachments: SGF_SF_interaction.patch.txt > > Time Spent: 4h > Remaining Estimate: 0h > > [~janhoy] find the bug. > In an analyzer with e.g. stopFilter where tokens are removed from the stream > and replaced with a “hole”, synonymgraphfilter will not preserve these holes > but remove them, resulting in certain phrase queries failing. -- 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 #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
dsmiley commented on a change in pull request #1819: URL: https://github.com/apache/lucene-solr/pull/1819#discussion_r482097781 ## File path: solr/solr-ref-guide/src/the-query-elevation-component.adoc ## @@ -61,7 +61,18 @@ Optionally, in the Query Elevation Component configuration you can also specify The Query Elevation Search Component takes the following parameters: `queryFieldType`:: -Specifies which fieldType should be used to analyze the incoming text. For example, it may be appropriate to use a fieldType with a LowerCaseFilter. +Specifies which fieldType should be used to analyze the incoming text. For example, it may be appropriate to use a fieldType with a LowerCaseFilter. Other example, if you need to unescape backslash-escaped queries, then you can define the fieldType to preprocess with a PatternReplaceCharFilter. Here is the corresponding example of fieldType (traditionally in `schema.xml`): + +[source,xml] + + + + Review comment: I think there's a syntax to use such that we only un-escape non-alphanumeric? If they type a\b (which might be in some identifier) then they probably meant 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] mayya-sharipova commented on a change in pull request #1725: LUCENE-9449 Skip docs with _doc sort and "after"
mayya-sharipova commented on a change in pull request #1725:
URL: https://github.com/apache/lucene-solr/pull/1725#discussion_r482105620
##
File path:
lucene/core/src/java/org/apache/lucene/search/comparators/DocComparator.java
##
@@ -0,0 +1,183 @@
+/*
+ * 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.search.comparators;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.search.DocIdSetIterator;
+import org.apache.lucene.search.FieldComparator;
+import org.apache.lucene.search.LeafFieldComparator;
+import org.apache.lucene.search.Scorable;
+
+import java.io.IOException;
+
+/**
+ * Comparator that sorts by asc _doc
+ */
+public class DocComparator extends FieldComparator {
+private final int[] docIDs;
+private final boolean enableSkipping; // if skipping functionality should
be enabled
+private int bottom;
+private int topValue;
+private boolean topValueSet;
+private boolean bottomValueSet;
+private boolean hitsThresholdReached;
+
+/** Creates a new comparator based on document ids for {@code numHits} */
+public DocComparator(int numHits, boolean reverse) {
+this.docIDs = new int[numHits];
+// skipping functionality is enabled if we are sorting by _doc in asc
order
Review comment:
@jimczi Thanks for the feedback.
> I was thinking that we could use the information exposed in
SortField#getComparator, we don't need to add a new callback
Good point, I haven't noticed that before, I've refactored the code to use
`sortPos` from this function.
> However, I think we can rely on what you describe above,
setHitsThresholdReached and competitiveIterator are the callbacks that we need
to enable the optimization. ... we probably don't need 485fe4f
Doing sort optimization only on primary sort in `MultiLeafFieldComparator`
is implicit and some refactoring of it may bring wrong result. So I think it is
good to have extra protection
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-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189267#comment-17189267 ] Colvin Cowie commented on SOLR-14422: - No problem [~epugh], cheers > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- 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] bruno-roustant commented on a change in pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant commented on a change in pull request #1819: URL: https://github.com/apache/lucene-solr/pull/1819#discussion_r482110458 ## File path: solr/solr-ref-guide/src/the-query-elevation-component.adoc ## @@ -61,7 +61,18 @@ Optionally, in the Query Elevation Component configuration you can also specify The Query Elevation Search Component takes the following parameters: `queryFieldType`:: -Specifies which fieldType should be used to analyze the incoming text. For example, it may be appropriate to use a fieldType with a LowerCaseFilter. +Specifies which fieldType should be used to analyze the incoming text. For example, it may be appropriate to use a fieldType with a LowerCaseFilter. Other example, if you need to unescape backslash-escaped queries, then you can define the fieldType to preprocess with a PatternReplaceCharFilter. Here is the corresponding example of fieldType (traditionally in `schema.xml`): + +[source,xml] + + + + Review comment: Indeed, but do we want to go into this level of detail? The Lucene StandardQueryParser uses EscapeQuerySyntaxImpl.discardEscapeChar() which unescape everything without distinction except it detects unicode \u and converts it. I suggest that we give a basic example of unescaping every backslash. If the user wants more sophisticated logic, then she will design the right pattern or the custom CharFilter. 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] (SOLR-14787) Inequality support in Payload Check query parser
[
https://issues.apache.org/jira/browse/SOLR-14787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck reassigned SOLR-14787:
---
Assignee: Gus Heck
> Inequality support in Payload Check query parser
>
>
> Key: SOLR-14787
> URL: https://issues.apache.org/jira/browse/SOLR-14787
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal of this ticket/pull request is to support a richer set of matching
> and filtering based on term payloads. This patch extends the
> PayloadCheckQueryParser to add a new local param for "op"
> The value of OP could be one of the following
> * gt - greater than
> * gte - greater than or equal
> * lt - less than
> * lte - less than or equal
> default value for "op" if not specified is to be the current behavior of
> equals.
> Additionally to the operation you can specify a threshold local parameter
> This will provide the ability to search for the term "cat" so long as the
> payload has a value of greater than 0.75.
> One use case is to classify a document into various categories with an
> associated confidence or probability that the classification is correct.
> That can be indexed into a delimited payload field. The searches can find
> and match documents that were tagged with the "cat" category with a
> confidence of greater than 0.5.
> Example Document
> {code:java}
> {
> "id":"doc_1",
> "classifications_payload":["cat|0.75 dog|2.0"]
> }
> {code}
> Example Syntax
> {code:java}
> {!payload_check f=classifications_payload payloads='1' op='gt'
> threshold='0.5'}cat {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
[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant commented on a change in pull request #1819:
URL: https://github.com/apache/lucene-solr/pull/1819#discussion_r482119547
##
File path: solr/solr-ref-guide/src/the-query-elevation-component.adoc
##
@@ -61,7 +61,18 @@ Optionally, in the Query Elevation Component configuration
you can also specify
The Query Elevation Search Component takes the following parameters:
`queryFieldType`::
-Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter.
+Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter. Other
example, if you need to unescape backslash-escaped queries, then you can define
the fieldType to preprocess with a PatternReplaceCharFilter. Here is the
corresponding example of fieldType (traditionally in `schema.xml`):
+
+[source,xml]
+
+
+
+
Review comment:
The regex would be "\\([^\p{Alnum}])", but it applies to ASCII alphanum,
not internationalized.
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] mayya-sharipova commented on a change in pull request #1725: LUCENE-9449 Skip docs with _doc sort and "after"
mayya-sharipova commented on a change in pull request #1725:
URL: https://github.com/apache/lucene-solr/pull/1725#discussion_r482105620
##
File path:
lucene/core/src/java/org/apache/lucene/search/comparators/DocComparator.java
##
@@ -0,0 +1,183 @@
+/*
+ * 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.search.comparators;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.search.DocIdSetIterator;
+import org.apache.lucene.search.FieldComparator;
+import org.apache.lucene.search.LeafFieldComparator;
+import org.apache.lucene.search.Scorable;
+
+import java.io.IOException;
+
+/**
+ * Comparator that sorts by asc _doc
+ */
+public class DocComparator extends FieldComparator {
+private final int[] docIDs;
+private final boolean enableSkipping; // if skipping functionality should
be enabled
+private int bottom;
+private int topValue;
+private boolean topValueSet;
+private boolean bottomValueSet;
+private boolean hitsThresholdReached;
+
+/** Creates a new comparator based on document ids for {@code numHits} */
+public DocComparator(int numHits, boolean reverse) {
+this.docIDs = new int[numHits];
+// skipping functionality is enabled if we are sorting by _doc in asc
order
Review comment:
@jimczi Thanks for the feedback.
> I was thinking that we could use the information exposed in
SortField#getComparator, we don't need to add a new callback
Good point, I haven't noticed that before, I've refactored the code to use
`sortPos` from this function. Addressed in 92fa246
> However, I think we can rely on what you describe above,
setHitsThresholdReached and competitiveIterator are the callbacks that we need
to enable the optimization. ... we probably don't need 485fe4f
Doing sort optimization only on primary sort in `MultiLeafFieldComparator`
is implicit and some refactoring of it may bring wrong result. So I think it is
good to have extra protection
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] bruno-roustant commented on a change in pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant commented on a change in pull request #1819:
URL: https://github.com/apache/lucene-solr/pull/1819#discussion_r482119547
##
File path: solr/solr-ref-guide/src/the-query-elevation-component.adoc
##
@@ -61,7 +61,18 @@ Optionally, in the Query Elevation Component configuration
you can also specify
The Query Elevation Search Component takes the following parameters:
`queryFieldType`::
-Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter.
+Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter. Other
example, if you need to unescape backslash-escaped queries, then you can define
the fieldType to preprocess with a PatternReplaceCharFilter. Here is the
corresponding example of fieldType (traditionally in `schema.xml`):
+
+[source,xml]
+
+
+
+
Review comment:
The regex would be "([^\\p{Alnum}])", but it applies to ASCII
alphanum, not internationalized.
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] TomMD commented on a change in pull request #1818: SOLR-14819 Trivial fix to inefficient iterator pattern
TomMD commented on a change in pull request #1818: URL: https://github.com/apache/lucene-solr/pull/1818#discussion_r482121832 ## File path: .muse.toml ## @@ -0,0 +1 @@ +jdk11 = true Review comment: Woops, thanks for the catch that was for my own use. 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] [Created] (LUCENE-9499) Clean up package name conflicts between modules (split packages)
Tomoko Uchida created LUCENE-9499:
-
Summary: Clean up package name conflicts between modules (split
packages)
Key: LUCENE-9499
URL: https://issues.apache.org/jira/browse/LUCENE-9499
Project: Lucene - Core
Issue Type: Improvement
Affects Versions: master (9.0)
Reporter: Tomoko Uchida
Assignee: Tomoko Uchida
We have lots of package name conflicts (shared package names) between modules
in the source tree. It is not only annoying for devs/users but also indeed bad
practice since Java 9 (according to my understanding), and we already have some
problems with Javadocs due to these splitted packages as some of us would know.
Also split packages make migrating to the Java 9 module system impossible.
This is the placeholder to fix all package name conflicts in Lucene.
See the dev list thread for moe background.
[https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
Modules that need be fixed / cleaned up:
- analyzers-common (LUCENE-9317)
- analyzers-icu
- backward-codecs (LUCENE-9318)
- sandbox (LUCENE-9319)
- misc
- (test-framework: this can be excluded for the moment)
Also lucene-core will be heavily affected (some classes needed to be moved into
core, or some classes' and methods' in {{core}} visibility have to be relaxed).
--
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-9499) Clean up package name conflicts between modules (split packages)
[
https://issues.apache.org/jira/browse/LUCENE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-9499:
--
Fix Version/s: master (9.0)
> Clean up package name conflicts between modules (split packages)
>
>
> Key: LUCENE-9499
> URL: https://issues.apache.org/jira/browse/LUCENE-9499
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
>
> We have lots of package name conflicts (shared package names) between modules
> in the source tree. It is not only annoying for devs/users but also indeed
> bad practice since Java 9 (according to my understanding), and we already
> have some problems with Javadocs due to these splitted packages as some of us
> would know. Also split packages make migrating to the Java 9 module system
> impossible.
> This is the placeholder to fix all package name conflicts in Lucene.
> See the dev list thread for moe background.
>
> [https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
> Modules that need be fixed / cleaned up:
> - analyzers-common (LUCENE-9317)
> - analyzers-icu
> - backward-codecs (LUCENE-9318)
> - sandbox (LUCENE-9319)
> - misc
> - (test-framework: this can be excluded for the moment)
> Also lucene-core will be heavily affected (some classes needed to be moved
> into core, or some classes' and methods' in {{core}} visibility have to be
> relaxed).
--
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] bruno-roustant commented on a change in pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant commented on a change in pull request #1819:
URL: https://github.com/apache/lucene-solr/pull/1819#discussion_r482123493
##
File path: solr/solr-ref-guide/src/the-query-elevation-component.adoc
##
@@ -61,7 +61,18 @@ Optionally, in the Query Elevation Component configuration
you can also specify
The Query Elevation Search Component takes the following parameters:
`queryFieldType`::
-Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter.
+Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter. Other
example, if you need to unescape backslash-escaped queries, then you can define
the fieldType to preprocess with a PatternReplaceCharFilter. Here is the
corresponding example of fieldType (traditionally in `schema.xml`):
+
+[source,xml]
+
+
+
+
Review comment:
Actually it is possible to localize the pattern with
"([^\\p{javaLowerCase}\\p{javaUpperCase}\\p{Digit}])"
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] bruno-roustant commented on a change in pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant commented on a change in pull request #1819:
URL: https://github.com/apache/lucene-solr/pull/1819#discussion_r482123493
##
File path: solr/solr-ref-guide/src/the-query-elevation-component.adoc
##
@@ -61,7 +61,18 @@ Optionally, in the Query Elevation Component configuration
you can also specify
The Query Elevation Search Component takes the following parameters:
`queryFieldType`::
-Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter.
+Specifies which fieldType should be used to analyze the incoming text. For
example, it may be appropriate to use a fieldType with a LowerCaseFilter. Other
example, if you need to unescape backslash-escaped queries, then you can define
the fieldType to preprocess with a PatternReplaceCharFilter. Here is the
corresponding example of fieldType (traditionally in `schema.xml`):
+
+[source,xml]
+
+
+
+
Review comment:
Actually it is possible to localize the pattern with
"([^\\p{IsAlphabetic}\\p{Digit}])"
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] bruno-roustant commented on a change in pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant commented on a change in pull request #1819: URL: https://github.com/apache/lucene-solr/pull/1819#discussion_r482130641 ## File path: solr/solr-ref-guide/src/the-query-elevation-component.adoc ## @@ -61,7 +61,18 @@ Optionally, in the Query Elevation Component configuration you can also specify The Query Elevation Search Component takes the following parameters: `queryFieldType`:: -Specifies which fieldType should be used to analyze the incoming text. For example, it may be appropriate to use a fieldType with a LowerCaseFilter. +Specifies which fieldType should be used to analyze the incoming text. For example, it may be appropriate to use a fieldType with a LowerCaseFilter. Other example, if you need to unescape backslash-escaped queries, then you can define the fieldType to preprocess with a PatternReplaceCharFilter. Here is the corresponding example of fieldType (traditionally in `schema.xml`): + +[source,xml] + + + + Review comment: I added this other pattern as an example. 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-8985) SynonymGraphFilter cannot handle input stream with tokens filtered.
[
https://issues.apache.org/jira/browse/LUCENE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189288#comment-17189288
]
Michael McCandless commented on LUCENE-8985:
Thank you [~nppoly] for the thorough PR – I will try to review again soon.
Holes are a challenge for graph token filters. I have long felt that stop
words (and other holey tokens) should not be removed from the token stream, but
rather a new {{DeletedAttribute}} would mark the token as deleted (and not to
be indexed) but still the token would remain (and be {{incrementToken}}'d) to
record the metadata about that token for the sake of future token filter
stages. E.g. this would allow analyzers that mark stopwords for deletion but
then e.g. a {{SynonymGraphFilter}} could still apply over the stopwords, e.g.
{{lord of the rings}} could still match properly even if {{of}} and {{the}}
were marked as deleted. But, that is a much larger change, and no need to hold
up this first approach for that!
> SynonymGraphFilter cannot handle input stream with tokens filtered.
> ---
>
> Key: LUCENE-8985
> URL: https://issues.apache.org/jira/browse/LUCENE-8985
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Chongchen Chen
>Priority: Major
> Fix For: 8.3
>
> Attachments: SGF_SF_interaction.patch.txt
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> [~janhoy] find the bug.
> In an analyzer with e.g. stopFilter where tokens are removed from the stream
> and replaced with a “hole”, synonymgraphfilter will not preserve these holes
> but remove them, resulting in certain phrase queries failing.
--
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-9499) Clean up package name conflicts between modules (split packages)
[
https://issues.apache.org/jira/browse/LUCENE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-9499:
--
Description:
We have lots of package name conflicts (shared package names) between modules
in the source tree. It is not only annoying for devs/users but also indeed bad
practice since Java 9 (according to my understanding), and we already have some
problems with Javadocs due to these splitted packages as some of us would know.
Also split packages make migrating to the Java 9 module system impossible.
This is the placeholder to fix all package name conflicts in Lucene.
See the dev list thread for moe background.
[https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
Modules that need be fixed / cleaned up:
- analyzers-common (LUCENE-9317)
- analyzers-icu
- backward-codecs (LUCENE-9318)
- sandbox (LUCENE-9319)
- misc
- (test-framework: this can be excluded for the moment)
Also lucene-core will be heavily affected (some classes needed to be moved into
core, or some classes' and methods' in {{core}} visibility have to be relaxed).
Probably most work would be done in a parallel manner, but conflicts can
happen. If someone want to help out, please open an issue before working and
share your thoughts with me and others.
I set "Fix version" to 9.0 - means once we make a commit here, this will be a
blocker for release 9.0.0. (I don't think the changes should be delivered
across two major releases; all changes have to be out at once in a major
release.) If there are any objections or concerns, please leave comments. For
now I have no idea about the total volume of changes or technical obstacles
that have to be handled.
was:
We have lots of package name conflicts (shared package names) between modules
in the source tree. It is not only annoying for devs/users but also indeed bad
practice since Java 9 (according to my understanding), and we already have some
problems with Javadocs due to these splitted packages as some of us would know.
Also split packages make migrating to the Java 9 module system impossible.
This is the placeholder to fix all package name conflicts in Lucene.
See the dev list thread for moe background.
[https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
Modules that need be fixed / cleaned up:
- analyzers-common (LUCENE-9317)
- analyzers-icu
- backward-codecs (LUCENE-9318)
- sandbox (LUCENE-9319)
- misc
- (test-framework: this can be excluded for the moment)
Also lucene-core will be heavily affected (some classes needed to be moved into
core, or some classes' and methods' in {{core}} visibility have to be relaxed).
> Clean up package name conflicts between modules (split packages)
>
>
> Key: LUCENE-9499
> URL: https://issues.apache.org/jira/browse/LUCENE-9499
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
>
> We have lots of package name conflicts (shared package names) between modules
> in the source tree. It is not only annoying for devs/users but also indeed
> bad practice since Java 9 (according to my understanding), and we already
> have some problems with Javadocs due to these splitted packages as some of us
> would know. Also split packages make migrating to the Java 9 module system
> impossible.
> This is the placeholder to fix all package name conflicts in Lucene.
> See the dev list thread for moe background.
>
> [https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
> Modules that need be fixed / cleaned up:
> - analyzers-common (LUCENE-9317)
> - analyzers-icu
> - backward-codecs (LUCENE-9318)
> - sandbox (LUCENE-9319)
> - misc
> - (test-framework: this can be excluded for the moment)
> Also lucene-core will be heavily affected (some classes needed to be moved
> into core, or some classes' and methods' in {{core}} visibility have to be
> relaxed).
> Probably most work would be done in a parallel manner, but conflicts can
> happen. If someone want to help out, please open an issue before working and
> share your thoughts with me and others.
> I set "Fix version" to 9.0 - means once we make a commit here, this will be a
> blocker for release 9.0.0. (I don't think the changes should be delivered
> across two major releases; all changes have to be out at once in a major
> release.) If there are any objections or concerns, please leave comments. For
> now I have no idea about the total volume of changes or technic
[jira] [Commented] (LUCENE-9499) Clean up package name conflicts between modules (split packages)
[
https://issues.apache.org/jira/browse/LUCENE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189299#comment-17189299
]
Tomoko Uchida commented on LUCENE-9499:
---
I will firstly (re)start [LUCENE-9317].
> Clean up package name conflicts between modules (split packages)
>
>
> Key: LUCENE-9499
> URL: https://issues.apache.org/jira/browse/LUCENE-9499
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
>
> We have lots of package name conflicts (shared package names) between modules
> in the source tree. It is not only annoying for devs/users but also indeed
> bad practice since Java 9 (according to my understanding), and we already
> have some problems with Javadocs due to these splitted packages as some of us
> would know. Also split packages make migrating to the Java 9 module system
> impossible.
> This is the placeholder to fix all package name conflicts in Lucene.
> See the dev list thread for moe background.
>
> [https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
> Modules that need be fixed / cleaned up:
> - analyzers-common (LUCENE-9317)
> - analyzers-icu
> - backward-codecs (LUCENE-9318)
> - sandbox (LUCENE-9319)
> - misc
> - (test-framework: this can be excluded for the moment)
> Also lucene-core will be heavily affected (some classes needed to be moved
> into core, or some classes' and methods' in {{core}} visibility have to be
> relaxed).
> Probably most work would be done in a parallel manner, but conflicts can
> happen. If someone want to help out, please open an issue before working and
> share your thoughts with me and others.
> I set "Fix version" to 9.0 - means once we make a commit here, this will be a
> blocker for release 9.0.0. (I don't think the changes should be delivered
> across two major releases; all changes have to be out at once in a major
> release.) If there are any objections or concerns, please leave comments. For
> now I have no idea about the total volume of changes or technical obstacles
> that have to be handled.
--
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-9215) replace checkJavaDocs.py with doclet
[
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189307#comment-17189307
]
Uwe Schindler commented on LUCENE-9215:
---
Thanks Robert Did you add a changes entry?
> replace checkJavaDocs.py with doclet
>
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when
> newer java change html output. This is not particularly fun to fix: see
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class
> across 11,12,13 it surprised me how much changes. So I think we want to avoid
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white.
> Either everything is fully documented or its not. And while you can
> enable/disable doclint checks per-package, this also seems black/white
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at
> different granularities (package, class, method). It makes it possible to
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match
> checkJavaDocs.py logic:
> {code}
> private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
> error(element, "javadocs are missing");
> } else {
> var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
> if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
> } else if (normalized.startsWith("licensed to the apache software
> foundation") ||
> normalized.startsWith("copyright 2004 the apache software
> foundation")) {
> error(element, "comment is really a license");
> }
> }
> {code}
> If there are problems then they just appear as errors from the output of
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
> error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
> error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
> error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
> error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
> error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
> error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
> error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
> error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
> error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
> error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
> error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
> error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
> error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
> error - NoDoc (class): javadocs are missing
[jira] [Updated] (LUCENE-9499) Clean up package name conflicts between modules (split packages)
[
https://issues.apache.org/jira/browse/LUCENE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-9499:
--
Description:
We have lots of package name conflicts (shared package names) between modules
in the source tree. It is not only annoying for devs/users but also indeed bad
practice since Java 9 (according to my understanding), and we already have some
problems with Javadocs due to these splitted packages as some of us would know.
Also split packages make migrating to the Java 9 module system impossible.
This is the placeholder to fix all package name conflicts in Lucene.
See the dev list thread for more background.
[https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
Modules that need to be fixed / cleaned up:
- analyzers-common (LUCENE-9317)
- analyzers-icu
- backward-codecs (LUCENE-9318)
- sandbox (LUCENE-9319)
- misc
- (test-framework: this can be excluded for the moment)
Also lucene-core will be heavily affected (some classes have to be moved into
{{core}}, or some classes' and methods' in {{core}} visibility have to be
relaxed).
Probably most work would be done in a parallel manner, but conflicts can
happen. If someone want to help out, please open an issue before working and
share your thoughts with me and others.
I set "Fix version" to 9.0 - means once we make a commit on here, this will be
a blocker for release 9.0.0. (I don't think the changes should be delivered
across two major releases; all changes have to be out at once in a major
release.) If there are any objections or concerns, please leave comments. For
now I have no idea about the total volume of changes or technical obstacles
that have to be handled.
was:
We have lots of package name conflicts (shared package names) between modules
in the source tree. It is not only annoying for devs/users but also indeed bad
practice since Java 9 (according to my understanding), and we already have some
problems with Javadocs due to these splitted packages as some of us would know.
Also split packages make migrating to the Java 9 module system impossible.
This is the placeholder to fix all package name conflicts in Lucene.
See the dev list thread for moe background.
[https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
Modules that need be fixed / cleaned up:
- analyzers-common (LUCENE-9317)
- analyzers-icu
- backward-codecs (LUCENE-9318)
- sandbox (LUCENE-9319)
- misc
- (test-framework: this can be excluded for the moment)
Also lucene-core will be heavily affected (some classes needed to be moved into
core, or some classes' and methods' in {{core}} visibility have to be relaxed).
Probably most work would be done in a parallel manner, but conflicts can
happen. If someone want to help out, please open an issue before working and
share your thoughts with me and others.
I set "Fix version" to 9.0 - means once we make a commit here, this will be a
blocker for release 9.0.0. (I don't think the changes should be delivered
across two major releases; all changes have to be out at once in a major
release.) If there are any objections or concerns, please leave comments. For
now I have no idea about the total volume of changes or technical obstacles
that have to be handled.
> Clean up package name conflicts between modules (split packages)
>
>
> Key: LUCENE-9499
> URL: https://issues.apache.org/jira/browse/LUCENE-9499
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
>
> We have lots of package name conflicts (shared package names) between modules
> in the source tree. It is not only annoying for devs/users but also indeed
> bad practice since Java 9 (according to my understanding), and we already
> have some problems with Javadocs due to these splitted packages as some of us
> would know. Also split packages make migrating to the Java 9 module system
> impossible.
> This is the placeholder to fix all package name conflicts in Lucene.
> See the dev list thread for more background.
>
> [https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
> Modules that need to be fixed / cleaned up:
> - analyzers-common (LUCENE-9317)
> - analyzers-icu
> - backward-codecs (LUCENE-9318)
> - sandbox (LUCENE-9319)
> - misc
> - (test-framework: this can be excluded for the moment)
> Also lucene-core will be heavily affected (some classes have to be moved into
> {{core}}, or some classes' and methods' in {{c
[jira] [Commented] (LUCENE-9317) Resolve package name conflicts for StandardAnalyzer to allow Java module system support
[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189318#comment-17189318
]
Tomoko Uchida commented on LUCENE-9317:
---
[~uschindler] can I ask your thoughts on my design for moving classes /
renaming packages?
> Resolve package name conflicts for StandardAnalyzer to allow Java module
> system support
> ---
>
> Key: LUCENE-9317
> URL: https://issues.apache.org/jira/browse/LUCENE-9317
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Affects Versions: master (9.0)
>Reporter: David Ryan
>Priority: Major
> Labels: build, features
>
>
> To allow Lucene to be modularised there are a few preparatory tasks to be
> completed prior to this being possible. The Java module system requires that
> jars do not use the same package name in different jars. The lucene-core and
> lucene-analyzers-common both share the package
> org.apache.lucene.analysis.standard.
> Possible resolutions to this issue are discussed by Uwe on the mailing list
> here:
>
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAM21Rt8FHOq_JeUSELhsQJH0uN0eKBgduBQX4fQKxbs49TLqzA%40mail.gmail.com%3E]
> {quote}About StandardAnalyzer: Unfortunately I aggressively complained a
> while back when Mike McCandless wanted to move standard analyzer out of the
> analysis package into core (“for convenience”). This was a bad step, and IMHO
> we should revert that or completely rename the packages and everything. The
> problem here is: As the analysis services are only part of lucene-analyzers,
> we had to leave the factory classes there, but move the implementation
> classes in core. The package has to be the same. The only way around that is
> to move the analysis factory framework also to core (I would not be against
> that). This would include all factory base classes and the service loading
> stuff. Then we can move standard analyzer and some of the filters/tokenizers
> including their factories to core an that problem would be solved.
> {quote}
> There are two options here, either move factory framework into core or revert
> StandardAnalyzer back to lucene-analyzers. In the email, the solution lands
> on reverting back as per the task list:
> {quote}Add some preparatory issues to cleanup class hierarchy: Move Analysis
> SPI to core / remove StandardAnalyzer and related classes out of core back to
> anaysis
> {quote}
>
>
>
>
--
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 merged pull request #1797: LUCENE ExitableReaderException public constructor
dsmiley merged pull request #1797: URL: https://github.com/apache/lucene-solr/pull/1797 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 a change in pull request #1687: SOLR-14658: Fix colstatus solrj interfaces to return one or all collections
dsmiley commented on a change in pull request #1687:
URL: https://github.com/apache/lucene-solr/pull/1687#discussion_r474312456
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java
##
@@ -517,10 +517,7 @@ private static void addStatusToResponse(NamedList
results, RequestStatus
ColStatus.RAW_SIZE_DETAILS_PROP,
ColStatus.RAW_SIZE_SAMPLING_PERCENT_PROP,
ColStatus.SIZE_INFO_PROP);
- // make sure we can get the name if there's "name" but not "collection"
- if (props.containsKey(CoreAdminParams.NAME) &&
!props.containsKey(COLLECTION_PROP)) {
Review comment:
CC @sigram I believe you added the lines of code here that Andy thinks
should be removed.
##
File path: solr/core/src/test/org/apache/solr/cloud/CollectionsAPISolrJTest.java
##
@@ -662,6 +662,44 @@ public void testColStatus() throws Exception {
Number down = (Number) rsp.getResponse().findRecursive(collectionName,
"shards", "shard1", "replicas", "down");
assertTrue("should be some down replicas, but there were none in shard1:"
+ rsp, down.intValue() > 0);
}
+
+ @Test
+ public void testColStatusCollectionName() throws Exception {
+final String[] collectionNames = {"collectionStatusTest_1",
"collectionStatusTest_2"};
+for (String collectionName : collectionNames) {
+ CollectionAdminRequest.createCollection(collectionName, "conf2", 1, 1)
+ .process(cluster.getSolrClient());
+ cluster.waitForActiveCollection(collectionName, 1, 1);
+}
+// assert only one collection is returned using the solrj colstatus
interface
+CollectionAdminRequest.ColStatus req =
CollectionAdminRequest.collectionStatus(collectionNames[0]);
+CollectionAdminResponse rsp = req.process(cluster.getSolrClient());
+assertNotNull(rsp.getResponse().get(collectionNames[0]));
+assertNull(rsp.getResponse().get(collectionNames[1]));
+
+req = CollectionAdminRequest.collectionStatus(collectionNames[1]);
+rsp = req.process(cluster.getSolrClient());
+assertNotNull(rsp.getResponse().get(collectionNames[1]));
+assertNull(rsp.getResponse().get(collectionNames[0]));
+
+// assert passing null collection fails
+try {
Review comment:
please convert to expectThrows
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-14782) QueryElevationComponent does not handle escaped query terms
[
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189323#comment-17189323
]
ASF subversion and git services commented on SOLR-14782:
Commit 56dbb6650356ba1292bd38aa5ad669fddd8ee50b in lucene-solr's branch
refs/heads/master from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=56dbb66 ]
SOLR-14782: Document how to unescape for the QueryElevationComponent.
> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
> Labels: elevation
> Attachments: SOLR-14782.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa
> bbb"{color}><{color:#0033b3}doc
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2"
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component
> "QueryElevationComponent" does not unescape the query term bevor the lookup
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>
--
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] bruno-roustant closed pull request #1819: SOLR-14782: Document how to unescape for the QueryElevationComponent.
bruno-roustant closed pull request #1819: URL: https://github.com/apache/lucene-solr/pull/1819 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 #1687: SOLR-14658: Fix colstatus solrj interfaces to return one or all collections
dsmiley commented on pull request #1687: URL: https://github.com/apache/lucene-solr/pull/1687#issuecomment-685826394 In addition to the minor expectThrows addition, @andyvuong can you also please add a CHANGES.txt entry for 8.7 in the bug section? Perhaps something like: * SOLR-14658: SolrJ's CollectionAdminRequest.collectionStatus(collection) would internally get all collection statuses instead of just for the specified collection. (Andy Vuong) Maybe this even goes under the "Optimization" section? From a user's standpoint, that's what this is. It wasn't broken before. 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] [Created] (LUCENE-9500) Did we hit a DEFLATE bug?
Adrien Grand created LUCENE-9500: Summary: Did we hit a DEFLATE bug? Key: LUCENE-9500 URL: https://issues.apache.org/jira/browse/LUCENE-9500 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand I've been digging [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] all day and managed to isolate a simple reproduction that shows the problem. I've been starring at it all day and can't find what we are doing wrong, which makes me wonder whether we're calling DEFLATE the wrong way or whether we hit a DEFLATE bug. I've looked at it so much that I may be missing the most obvious stuff. -- 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-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-9500: - Attachment: PresetDictTest.java Status: Open (was: Open) > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Attachments: PresetDictTest.java, test_data.txt > > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- 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-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-9500: - Attachment: test_data.txt Status: Open (was: Open) > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Attachments: PresetDictTest.java, test_data.txt > > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- 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-9495) Ref Guide gradle buildSite ignores version parameter
[
https://issues.apache.org/jira/browse/LUCENE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189333#comment-17189333
]
Cassandra Targett commented on LUCENE-9495:
---
{quote} * it's been renamed (probably to be more "gradle-esque" ?) using camel
case: solrGuideVersion
* it has to be specified using '-P' (which is evidently the gradle way of
setting project properties on the command line
{quote}
Thank you. I had tried the camelCase version after looking in the build.gradle,
the thing I was missing was the {{-P}} instead of {{-D}}.
I think Dawid, you're saying that it will now take {{-D}} also? Should people
prefer {{-P}}? I just want to get the docs right.
Thanks to you both - I'll file a separate Solr issue about simplifying the
params in general.
> Ref Guide gradle buildSite ignores version parameter
>
>
> Key: LUCENE-9495
> URL: https://issues.apache.org/jira/browse/LUCENE-9495
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Reporter: Cassandra Targett
>Priority: Major
>
> All Ref Guide builds by default are built as drafts. A DRAFT watermark is
> inserted on to every page, a special header is added to the side navigation,
> and the footer version includes the word "-DRAFT".
> To accomplish this, the guide has long used a parameter
> {{solr-guide-version}} to indicate when a build for the Ref Guide _should
> not_ be considered a draft. With the Gradle build, this no longer works. (I
> thought I'd tested this, but either I missed it or it broke at some point in
> between.)
> [~hossman] set this up several years ago, so cc'ing him here so he can take a
> look and see why the logic would stop working now.
> Links:
> Ref Guide {{build.gradle}} that determines Guide version:
> https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/build.gradle#L128
> Ant {{build.xml}} the above was adapted from:
> https://github.com/apache/lucene-solr/blob/branch_8x/solr/solr-ref-guide/build.xml#L70
>
> Beyond getting this to work, I think it's worth a discussion (separate Jira?)
> about whether we can simplify it. Maybe just a parameter
> {{ref-guide-draft=false}} would be sufficient? We might also reconsider the
> variations of versions in the Ref Guide params and whether we really need
> them ({{solr-guide-version}}, {{solr-docs-version}}).
--
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-9500) Did we hit a DEFLATE bug?
[
https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189332#comment-17189332
]
Adrien Grand commented on LUCENE-9500:
--
I just attached the test and test data I used that recreates the issue. I get
the following output:
{noformat}
Compressed to 115 bytes
First mismatch byte 0
First original bytes [c0 9a e2 81 24 d5 fc 9 9 49 f c0 9a e2 81 24 d5 fc 9 9 49
f c0 9a e2 81 24 d5 fc 9]
First restored bytes [9 9 49 f c0 9a e2 81 24 d5 fc 9 9 49 f c0 9a e2 81 24 d5
fc 9 9 49 f c0 9a e2 81]
Exception in thread "main" java.lang.Error
at PresetDictTest.main(PresetDictTest.java:87)
{noformat}
If I remove the call to setDictionary on the compression side, then no error.
> Did we hit a DEFLATE bug?
> -
>
> Key: LUCENE-9500
> URL: https://issues.apache.org/jira/browse/LUCENE-9500
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: PresetDictTest.java, test_data.txt
>
>
> I've been digging
> [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/]
> all day and managed to isolate a simple reproduction that shows the problem.
> I've been starring at it all day and can't find what we are doing wrong,
> which makes me wonder whether we're calling DEFLATE the wrong way or whether
> we hit a DEFLATE bug. I've looked at it so much that I may be missing the
> most obvious stuff.
--
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-9215) replace checkJavaDocs.py with doclet
[
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189334#comment-17189334
]
Dawid Weiss commented on LUCENE-9215:
-
Thanks for chipping at this, Robert. This is big lateral effort to get rid of
legacy stuff.
> replace checkJavaDocs.py with doclet
>
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when
> newer java change html output. This is not particularly fun to fix: see
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class
> across 11,12,13 it surprised me how much changes. So I think we want to avoid
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white.
> Either everything is fully documented or its not. And while you can
> enable/disable doclint checks per-package, this also seems black/white
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at
> different granularities (package, class, method). It makes it possible to
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match
> checkJavaDocs.py logic:
> {code}
> private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
> error(element, "javadocs are missing");
> } else {
> var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
> if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
> } else if (normalized.startsWith("licensed to the apache software
> foundation") ||
> normalized.startsWith("copyright 2004 the apache software
> foundation")) {
> error(element, "comment is really a license");
> }
> }
> {code}
> If there are problems then they just appear as errors from the output of
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
> error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
> error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
> error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
> error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
> error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
> error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
> error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
> error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
> error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
> error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
> error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
> error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
> error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
> er
[jira] [Commented] (SOLR-14782) QueryElevationComponent does not handle escaped query terms
[
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189337#comment-17189337
]
ASF subversion and git services commented on SOLR-14782:
Commit 838bd16b8442855303358834147e894c3ba84071 in lucene-solr's branch
refs/heads/branch_8x from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=838bd16 ]
SOLR-14782: Document how to unescape for the QueryElevationComponent.
> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
> Labels: elevation
> Attachments: SOLR-14782.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa
> bbb"{color}><{color:#0033b3}doc
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2"
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component
> "QueryElevationComponent" does not unescape the query term bevor the lookup
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>
--
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-9495) Ref Guide gradle buildSite ignores version parameter
[
https://issues.apache.org/jira/browse/LUCENE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189340#comment-17189340
]
Dawid Weiss commented on LUCENE-9495:
-
Correct - -P is (one) of the ways to pass project properties in gradle [1]. I
did add some scaffolding to make -D work (-D sets a system property for
gradle's JVM) but it's really for convenience.
[1]
https://docs.gradle.org/current/userguide/build_environment.html#sec:project_properties
bq. Thanks to you both - I'll file a separate Solr issue about simplifying the
params in general.
This would be nice. There were a number of parameters that seemed like
duplicates or aliases of each other. I wasn't sure which ones were in use so I
ported them all but I'm sure it could be simplified somehow.
> Ref Guide gradle buildSite ignores version parameter
>
>
> Key: LUCENE-9495
> URL: https://issues.apache.org/jira/browse/LUCENE-9495
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Reporter: Cassandra Targett
>Priority: Major
>
> All Ref Guide builds by default are built as drafts. A DRAFT watermark is
> inserted on to every page, a special header is added to the side navigation,
> and the footer version includes the word "-DRAFT".
> To accomplish this, the guide has long used a parameter
> {{solr-guide-version}} to indicate when a build for the Ref Guide _should
> not_ be considered a draft. With the Gradle build, this no longer works. (I
> thought I'd tested this, but either I missed it or it broke at some point in
> between.)
> [~hossman] set this up several years ago, so cc'ing him here so he can take a
> look and see why the logic would stop working now.
> Links:
> Ref Guide {{build.gradle}} that determines Guide version:
> https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/build.gradle#L128
> Ant {{build.xml}} the above was adapted from:
> https://github.com/apache/lucene-solr/blob/branch_8x/solr/solr-ref-guide/build.xml#L70
>
> Beyond getting this to work, I think it's worth a discussion (separate Jira?)
> about whether we can simplify it. Maybe just a parameter
> {{ref-guide-draft=false}} would be sufficient? We might also reconsider the
> variations of versions in the Ref Guide params and whether we really need
> them ({{solr-guide-version}}, {{solr-docs-version}}).
--
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-14782) QueryElevationComponent does not handle escaped query terms
[
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Roustant resolved SOLR-14782.
---
Fix Version/s: 8.7
Resolution: Fixed
No code change. Fixed by adding an example of how to unescape for
QueryElevationComponent in the doc.
Thanks Thomas for pointing this.
> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
> Labels: elevation
> Fix For: 8.7
>
> Attachments: SOLR-14782.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa
> bbb"{color}><{color:#0033b3}doc
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2"
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component
> "QueryElevationComponent" does not unescape the query term bevor the lookup
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>
--
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-9496) Replace (or accelerate) check-broken-links.gradle with a doclet pass
[ https://issues.apache.org/jira/browse/LUCENE-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189349#comment-17189349 ] Dawid Weiss commented on LUCENE-9496: - There is definitely some effort in parsing those links (especially cross-code links) and verifying what's valid and what's suspicious (or wrong). It is quite fun though (like I said, I touched that API before) and isolated. Maybe somebody with some time on their hands would be willing to undertake it. I'd really like to move forward the build split that's needed for Solr TLP task. This part is crucial for other things (proper packaging, maven, etc.) - they're all intertwined. All this isn't in any way related to my daily job or life in general so apologies for slow progress; open source is still a hobby for some of us. :) > Replace (or accelerate) check-broken-links.gradle with a doclet pass > > > Key: LUCENE-9496 > URL: https://issues.apache.org/jira/browse/LUCENE-9496 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Minor > > This is just a placeholder, but perhaps somebody will find the time to push > this forward. The current python script in check-broken-links reparses all > emitted HTML files to find links. I have a strong feeling this could be done > better. > Javadoc doclets have access to parse trees for both the code and the javadoc > comments (including information about HTML tags, code links, etc.). For > example, this information is used by the built-in javac HTML linter. > Maybe we could replace the python linter entirely; verify where code links > will point at, where existing HTML links point to and validate this > information. I wrote some of that link-parsing code in Carrot2 (to convert > javadocs into a structured JSON format used in other documentation). The code > there is free to eyeball and borrow, if needed. > https://docs.oracle.com/en/java/javase/11/docs/api/jdk.compiler/com/sun/source/util/DocTreeScanner.html > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/JavaDocsVisitor.java#L135 > https://github.com/carrot2/carrot2/blob/master/infra/jsondoclet/src/main/java/com/carrotsearch/jsondoclet/PlainReferenceConverter.java -- 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-8319) A Time-limiting collector that works with CollectorManagers
[
https://issues.apache.org/jira/browse/LUCENE-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189352#comment-17189352
]
Michael McCandless commented on LUCENE-8319:
{quote}Timeout handling seems to be a frequent need so maybe we should add
support for it directly on IndexSearcher where we could more easily do the
right thing?
{quote}
+1 to implement this in {{IndexSearcher}}, carefully. The exponential backoff
sounds like a great approach!
> A Time-limiting collector that works with CollectorManagers
> ---
>
> Key: LUCENE-8319
> URL: https://issues.apache.org/jira/browse/LUCENE-8319
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Reporter: Tony Xu
>Priority: Minor
>
> Currently Lucene has *TimeLimitingCollector* to support time-bound collection
> and it will throw
> *TimeExceededException* if timeout happens. This only works nicely with the
> single-thread low-level API from the IndexSearcher. The method signature is --
> *void search(List leaves, Weight weight, Collector
> collector)*
> The intended use is to always enclose the searcher.search(query, collector)
> call with a try ... catch and handle the timeout exception. Unfortunately
> when working with a *CollectorManager* in the multi-thread search context,
> the *TimeExceededException* thrown during collecting one leaf slice will be
> re-thrown by *IndexSearcher* without calling *CollectorManager*'s reduce(),
> even if other slices are successfully collected. The signature
> of the search api with *CollectorManager* is --
> * T search(Query query, CollectorManager
> collectorManager)*
>
> The good news is that IndexSearcher handles *CollectionTerminatedException*
> gracefully by ignoring it. We can either wrap TimeLimitingCollector and throw
> *CollectionTerminatedException* when timeout happens or simply replace
> *TimeExceededException* with *CollectionTerminatedException*. In either way,
> we also need to maintain a flag that indicates if timeout occurred so that
> the user know it's a partial collection.
--
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 pull request #1684: SOLR-14613: strongly typed placement plugin interface and implementation
dsmiley commented on pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-685841854 I think use of solr.xml for this is pragmatic/realistic with the Solr we have today. And it's flexible -- can go on the node or in ZK as you desire, and can hold structured information (not just a bag of name-value pairs). This matter can be improved in the future. Some of the other discussion seems to be rooted in a trade-off: assuming there's an efficient plugin (minimally communicates with nodes to get data to make decisions), where does the complexity go relating to concurrency of node communication or knowledge of what nodes to even talk to? If this is in Solr, it can be independently optimized of plugins and makes an autoscaling plugin simpler to write _well_ (because it doesn't need to concern itself with many efficiencies). If we leave the complexity to a plugin writer, Solr is leaner. I don't think this is related to the problems of the previous autoscaling code we got rid of -- I don't think that either path will lead to eventual removal of what's added. A third matter is more a matter of taste on wether it's better/worse to have typed properties (not just in the primitive nature but it's identity / semantic). Trade-offs. I don't like an explosion of classes but I think this is highly mitigated by them being defined as simple inner classes of one outer class, as Ilan has done. 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-9500) Did we hit a DEFLATE bug?
[ https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189356#comment-17189356 ] Dawid Weiss commented on LUCENE-9500: - No idea. Send a repro to core-libs-...@openjdk.java.net? > Did we hit a DEFLATE bug? > - > > Key: LUCENE-9500 > URL: https://issues.apache.org/jira/browse/LUCENE-9500 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Attachments: PresetDictTest.java, test_data.txt > > > I've been digging > [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/] > all day and managed to isolate a simple reproduction that shows the problem. > I've been starring at it all day and can't find what we are doing wrong, > which makes me wonder whether we're calling DEFLATE the wrong way or whether > we hit a DEFLATE bug. I've looked at it so much that I may be missing the > most obvious stuff. -- 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-12239) Enabling index sorting causes "segment not sorted with indexSort=null"
[
https://issues.apache.org/jira/browse/SOLR-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189370#comment-17189370
]
Christine Poerschke commented on SOLR-12239:
ticket cross-referencing: might LUCENE-9484 solve the issue here?
> Enabling index sorting causes "segment not sorted with indexSort=null"
> --
>
> Key: SOLR-12239
> URL: https://issues.apache.org/jira/browse/SOLR-12239
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 7.1
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> When index sorting is enabled on an existing collection/index (using
> SortingMergePolicy), the collection reload causes the following exception:
> {code}
> java.util.concurrent.ExecutionException:
> org.apache.solr.common.SolrException: Unable to create core
> [mycoll_shard1_replica_n1]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at
> org.apache.solr.core.CoreContainer.lambda$load$14(CoreContainer.java:671)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.solr.common.SolrException: Unable to create core
> [mycoll_shard1_replica_n1]
> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1045)
> at
> org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:642)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Error opening new searcher
> at org.apache.solr.core.SolrCore.(SolrCore.java:989)
> at org.apache.solr.core.SolrCore.(SolrCore.java:844)
> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1029)
> ... 7 more
> Caused by: org.apache.solr.common.SolrException: Error opening new searcher
> at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2076)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2196)
> at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1072)
> at org.apache.solr.core.SolrCore.(SolrCore.java:961)
> ... 9 more
> Caused by: org.apache.lucene.index.CorruptIndexException: segment not sorted
> with indexSort=null (resource=_0(7.1.0):C1)
> at
> org.apache.lucene.index.IndexWriter.validateIndexSort(IndexWriter.java:1185)
> at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1108)
> at
> org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:119)
> at
> org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:94)
> at
> org.apache.solr.update.DefaultSolrCoreState.createMainIndexWriter(DefaultSolrCoreState.java:257)
> at
> org.apache.solr.update.DefaultSolrCoreState.getIndexWriter(DefaultSolrCoreState.java:131)
> at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2037)
> ... 12 more
> {code}
> This means that the user actually needs to delete the index segments, reload
> the collection and then re-index. This is bad user experience.
--
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
