[jira] [Updated] (SOLR-5604) Remove deprecations caused by httpclient 4.3.x upgrade
[ https://issues.apache.org/jira/browse/SOLR-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-5604: --- Attachment: SOLR-5604.patch Created a patch to prompt a discussion (some tests are broken) with a few highlights: * Updated HttpClientUtil to drop all of the setXXX methods, essentially the only thing remaining is the createClient(SolrParams...) * HttpClientConfigurer was updated to take a HttpClientBuilder and is properly setting all of the properties specified in HttpClientUtil * Created an abstract HttpClientSolrServer which allows for setters (internally mapping to the properties) then when the first time the getHttpClient() method is called, the client is created ** This is currently problematic in a few cases like CloudSolrServer or LBSolrServer because they call getHttpClient() in the constructor. Further work needs to be done to flesh this one out, generally when you are in this half-built state there is an init/@PostConstruct method that is called to finally build the client. Unfortunately you aren't able to get access to the ConnectionManager when using the HttpClientBuilder because it returns an 'InternalHttpClient' which doesn't give you access, it just returns a no-op manager when you call getConnectionManager(); Remove deprecations caused by httpclient 4.3.x upgrade -- Key: SOLR-5604 URL: https://issues.apache.org/jira/browse/SOLR-5604 Project: Solr Issue Type: Improvement Affects Versions: 4.7 Reporter: Shawn Heisey Fix For: 4.8, 5.0 Attachments: SOLR-5604-4x-just-lucene.patch, SOLR-5604.patch SOLR-5590 upgraded httpclient in Solr and Lucene to version 4.3.x. This version deprecates a LOT of classes and methods, recommending that they all be replaced with various methods from the HttpClientBuilder class. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5604) Remove deprecations caused by httpclient 4.3.x upgrade
[ https://issues.apache.org/jira/browse/SOLR-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-5604: --- Attachment: SOLR-5604.patch Remove deprecations caused by httpclient 4.3.x upgrade -- Key: SOLR-5604 URL: https://issues.apache.org/jira/browse/SOLR-5604 Project: Solr Issue Type: Improvement Affects Versions: 4.7 Reporter: Shawn Heisey Fix For: 4.8, 5.0 Attachments: SOLR-5604-4x-just-lucene.patch, SOLR-5604.patch SOLR-5590 upgraded httpclient in Solr and Lucene to version 4.3.x. This version deprecates a LOT of classes and methods, recommending that they all be replaced with various methods from the HttpClientBuilder class. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5604) Remove deprecations caused by httpclient 4.3.x upgrade
[ https://issues.apache.org/jira/browse/SOLR-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-5604: --- Attachment: (was: SOLR-5604.patch) Remove deprecations caused by httpclient 4.3.x upgrade -- Key: SOLR-5604 URL: https://issues.apache.org/jira/browse/SOLR-5604 Project: Solr Issue Type: Improvement Affects Versions: 4.7 Reporter: Shawn Heisey Fix For: 4.8, 5.0 Attachments: SOLR-5604-4x-just-lucene.patch, SOLR-5604.patch SOLR-5590 upgraded httpclient in Solr and Lucene to version 4.3.x. This version deprecates a LOT of classes and methods, recommending that they all be replaced with various methods from the HttpClientBuilder class. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4620) CloudSolrServer has single point of failure
[ https://issues.apache.org/jira/browse/SOLR-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-4620: --- Attachment: SOLR-4620.patch Patch for javadocs against trunk. Still needs CHANGES.txt. Does this look OK or should I do it differently? CloudSolrServer has single point of failure --- Key: SOLR-4620 URL: https://issues.apache.org/jira/browse/SOLR-4620 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Hardik Upadhyay Assignee: Mark Miller Priority: Minor Labels: features, patch Fix For: 4.8 Attachments: SOLR-4620.patch CloudSolrServer (solrj) has single point of failure.If the zookeeper node specified into cloud solr server client is down,solr client will fail. (Since purpose of zookeeper is to avoid such failures and to provide high availability) This seems to be a valid bug,as it violets single point of failure. Rather CloudSolrServer should accept list of zkHost and should not fail until a single zkHost is up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5604) Remove deprecations caused by httpclient 4.3.x upgrade
[ https://issues.apache.org/jira/browse/SOLR-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13936460#comment-13936460 ] Shawn Heisey commented on SOLR-5604: [~sdavids], thank you for putting work in on this. I promise to look at your patch when time permits. A note about deleting attachments, comments, and other things: Because Apache develops completely in the open, we prefer to keep all historical data in Jira unless there's a really compelling reason to delete it. Sometimes the trail of how we arrived and the mistakes we made getting there is just as important as the final solution. When you attach a file that has the same name as a previous version, Jira automatically greys out the download link for previous versions. See SOLR-2906 for an example of a patch that went through a number of revisions. Remove deprecations caused by httpclient 4.3.x upgrade -- Key: SOLR-5604 URL: https://issues.apache.org/jira/browse/SOLR-5604 Project: Solr Issue Type: Improvement Affects Versions: 4.7 Reporter: Shawn Heisey Fix For: 4.8, 5.0 Attachments: SOLR-5604-4x-just-lucene.patch, SOLR-5604.patch SOLR-5590 upgraded httpclient in Solr and Lucene to version 4.3.x. This version deprecates a LOT of classes and methods, recommending that they all be replaced with various methods from the HttpClientBuilder class. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Han Jiang closed LUCENE-3069. - Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2014 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Han Jiang resolved LUCENE-3069. --- Resolution: Fixed Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Han Jiang closed LUCENE-3069. - Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Han Jiang reopened LUCENE-3069: --- Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Han Jiang updated LUCENE-3069: -- Labels: gsoc2013 (was: gsoc2014) Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4620) CloudSolrServer has single point of failure
[ https://issues.apache.org/jira/browse/SOLR-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-4620: --- Attachment: SOLR-4620.patch Improved patch. CloudSolrServer has single point of failure --- Key: SOLR-4620 URL: https://issues.apache.org/jira/browse/SOLR-4620 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Hardik Upadhyay Assignee: Mark Miller Priority: Minor Labels: features, patch Fix For: 4.8 Attachments: SOLR-4620.patch, SOLR-4620.patch CloudSolrServer (solrj) has single point of failure.If the zookeeper node specified into cloud solr server client is down,solr client will fail. (Since purpose of zookeeper is to avoid such failures and to provide high availability) This seems to be a valid bug,as it violets single point of failure. Rather CloudSolrServer should accept list of zkHost and should not fail until a single zkHost is up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4620) CloudSolrServer has single point of failure
[ https://issues.apache.org/jira/browse/SOLR-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937040#comment-13937040 ] Varun Thacker commented on SOLR-4620: - Hi [~elyograg], I had created SOLR-5852 last week which pretty much does the same thing in addition to adding a additional constructor which accepts a list of ZK nodes and makes the comma separated string of ZK nodes. Should we merge the Javadocs and resolve the issue on SOLR-5852? CloudSolrServer has single point of failure --- Key: SOLR-4620 URL: https://issues.apache.org/jira/browse/SOLR-4620 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Hardik Upadhyay Assignee: Mark Miller Priority: Minor Labels: features, patch Fix For: 4.8 Attachments: SOLR-4620.patch, SOLR-4620.patch CloudSolrServer (solrj) has single point of failure.If the zookeeper node specified into cloud solr server client is down,solr client will fail. (Since purpose of zookeeper is to avoid such failures and to provide high availability) This seems to be a valid bug,as it violets single point of failure. Rather CloudSolrServer should accept list of zkHost and should not fail until a single zkHost is up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Reducing the number of warnings in the codebase
With the default settings in Eclipse, the Lucene/Solr codebase shows over 6000 warnings. This is the case for both branch_4x and trunk. I'm no expert, but this does seem a little excessive. If I were to take on the task of reducing this number, what advice can the group give me? Is there someone in particular that I should consider a resource for inevitable dumb questions? I haven't done an exhaustive survey, but I would imagine that most of them can be eliminated fairly easily. I'm fully aware that we may not be able to eliminate them all. One problem with fixing warnings is that the resulting patch(es) would be just as invasive as the recent work to move branch_4x to Java 7. This would complicate any ongoing work, especially large-scale work that is happening onchange-specific branches. A similar topic that may require a separate discussion: FindBugs. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4620) CloudSolrServer has single point of failure
[ https://issues.apache.org/jira/browse/SOLR-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937055#comment-13937055 ] Shawn Heisey commented on SOLR-4620: [~varunthacker], see my response on SOLR-5852. CloudSolrServer has single point of failure --- Key: SOLR-4620 URL: https://issues.apache.org/jira/browse/SOLR-4620 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Hardik Upadhyay Assignee: Mark Miller Priority: Minor Labels: features, patch Fix For: 4.8 Attachments: SOLR-4620.patch, SOLR-4620.patch CloudSolrServer (solrj) has single point of failure.If the zookeeper node specified into cloud solr server client is down,solr client will fail. (Since purpose of zookeeper is to avoid such failures and to provide high availability) This seems to be a valid bug,as it violets single point of failure. Rather CloudSolrServer should accept list of zkHost and should not fail until a single zkHost is up. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937054#comment-13937054
]
Shawn Heisey commented on SOLR-5852:
[~varunthacker] has proposed that we include the javadoc changes for SOLR-4620
on this issue. Before proceeding with this plan, I would like to hear from
committers with more seniority as to whether this change is a good idea.
My own gut reaction is that we should just stick with the format already
provided by zookeeper, especially since that's the only format that Solr itself
accepts when starting SolrCloud.
The current patch does not allow you to specify a chroot. You could check the
starting character and assume it's a chroot if it starts with a forward slash.
Unless you limited this check to the last argument, you'd need to throw an
exception if there were multiple chroots found and they were not all identical.
When I looked into whether it was possible to have two methods, here's what I
found: Eclipse does allow me to have foo(String,String...) as well as
foo(String...). This surprised me, because Java would likely ignore one of
them. Makes me wonder whether this is an oversight in the JDK, Eclipse, or
both. It wasn't even flagged by a FindBugs run.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937059#comment-13937059
]
Shawn Heisey commented on SOLR-5852:
Scratch what I just said about Eclipse allowing multiple ambiguous methods. It
actually does flag the problem, but it does it when you try to USE the method,
not at the actual method definitions.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937060#comment-13937060
]
Furkan KAMACI commented on SOLR-5852:
-
[~elyograg] I'will improve the patch as you said.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
Hi; I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 I can be volunteer to integrate Sonar into Lucene/Solr project. Thanks; Furkan KAMACI 2014-03-16 11:01 GMT+02:00 Shawn Heisey s...@elyograg.org: With the default settings in Eclipse, the Lucene/Solr codebase shows over 6000 warnings. This is the case for both branch_4x and trunk. I'm no expert, but this does seem a little excessive. If I were to take on the task of reducing this number, what advice can the group give me? Is there someone in particular that I should consider a resource for inevitable dumb questions? I haven't done an exhaustive survey, but I would imagine that most of them can be eliminated fairly easily. I'm fully aware that we may not be able to eliminate them all. One problem with fixing warnings is that the resulting patch(es) would be just as invasive as the recent work to move branch_4x to Java 7. This would complicate any ongoing work, especially large-scale work that is happening onchange-specific branches. A similar topic that may require a separate discussion: FindBugs. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937065#comment-13937065 ] Michael McCandless commented on LUCENE-3069: Woops, thanks for fixing the gsoc label Han! Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3004) Define Test Plan for 3.2
[ https://issues.apache.org/jira/browse/LUCENE-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3004. Resolution: Won't Fix I think the stable release process is working well w/o adding a test plan; smoke tester now helps us catch silly mistakes. Define Test Plan for 3.2 Key: LUCENE-3004 URL: https://issues.apache.org/jira/browse/LUCENE-3004 Project: Lucene - Core Issue Type: Test Reporter: Grant Ingersoll Priority: Minor Fix For: 4.8 Before we can release, we need a test plan that defines what a successful release candidate must do to be accepted. Test plan should be written at http://wiki.apache.org/lucene-java/TestPlans See http://www.lucidimagination.com/search/document/14bd01e519f39aff/brainstorming_on_improving_the_release_process -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5525) Implement MultiFacets.getAllDims
[ https://issues.apache.org/jira/browse/LUCENE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937079#comment-13937079 ] Michael McCandless commented on LUCENE-5525: bq. I reviewed MultiCategoryListsFacetsExample.java under lucene/demo – do you think it should use MultiFacets? And also exercise getAllDims()? I think MultiFacets usage there is a bit forced? But I did add a new testDrillSideways to SimpleFacetsExample, which uses getAllDims. Implement MultiFacets.getAllDims Key: LUCENE-5525 URL: https://issues.apache.org/jira/browse/LUCENE-5525 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7 Reporter: Jose Peleteiro Assignee: Michael McCandless Attachments: LUCENE-5525.patch DrillSideways.DrillSidewaysResult uses Facets when the query does not filter by a facet, but it uses MultiFacets when it does, and MultiFacets implementation is not complete. See: https://github.com/apache/lucene-solr/blob/0b0bc89932622f5bc2c4d74f978178b9ae15c700/lucene/facet/src/java/org/apache/lucene/facet/MultiFacets.java#L67 See http://pastebin.com/5eDbTM2v This code works when DrillDownQuery.add is not called (when there is no facets selected), but it fails with an UnsupportedOperationException. Perhaps I'm not using Facets correctly, but I'm trying to figure it out to upgrade from 4.6.1 by my self as I could not find a documentation other than javadocs for facets. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5525) Implement MultiFacets.getAllDims
[ https://issues.apache.org/jira/browse/LUCENE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5525: --- Attachment: LUCENE-5525.patch New patch, I think it's ready. Implement MultiFacets.getAllDims Key: LUCENE-5525 URL: https://issues.apache.org/jira/browse/LUCENE-5525 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7 Reporter: Jose Peleteiro Assignee: Michael McCandless Attachments: LUCENE-5525.patch, LUCENE-5525.patch DrillSideways.DrillSidewaysResult uses Facets when the query does not filter by a facet, but it uses MultiFacets when it does, and MultiFacets implementation is not complete. See: https://github.com/apache/lucene-solr/blob/0b0bc89932622f5bc2c4d74f978178b9ae15c700/lucene/facet/src/java/org/apache/lucene/facet/MultiFacets.java#L67 See http://pastebin.com/5eDbTM2v This code works when DrillDownQuery.add is not called (when there is no facets selected), but it fails with an UnsupportedOperationException. Perhaps I'm not using Facets correctly, but I'm trying to figure it out to upgrade from 4.6.1 by my self as I could not find a documentation other than javadocs for facets. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
Hi Shawn, +1 for the idea, we should take full advantage of Eclipse, IntelliJ etc. Here are some relevant tickets created by Furkan. https://issues.apache.org/jira/browse/LUCENE-5506 https://issues.apache.org/jira/browse/SOLR-5838 https://issues.apache.org/jira/browse/SOLR-5839 I believe https://issues.apache.org/jira/browse/SOLR-5685 could expressed as an automatic rule or something. There is already similar thing to detect usage of String.uppercase/lowercase without locale. And StringBuffer versus StringBuilder. Ahmet On Sunday, March 16, 2014 12:09 PM, Furkan KAMACI furkankam...@gmail.com wrote: Hi; I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 I can be volunteer to integrate Sonar into Lucene/Solr project. Thanks; Furkan KAMACI 2014-03-16 11:01 GMT+02:00 Shawn Heisey s...@elyograg.org: With the default settings in Eclipse, the Lucene/Solr codebase shows over 6000 warnings. This is the case for both branch_4x and trunk. I'm no expert, but this does seem a little excessive. If I were to take on the task of reducing this number, what advice can the group give me? Is there someone in particular that I should consider a resource for inevitable dumb questions? I haven't done an exhaustive survey, but I would imagine that most of them can be eliminated fairly easily. I'm fully aware that we may not be able to eliminate them all. One problem with fixing warnings is that the resulting patch(es) would be just as invasive as the recent work to move branch_4x to Java 7. This would complicate any ongoing work, especially large-scale work that is happening onchange-specific branches. A similar topic that may require a separate discussion: FindBugs. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5525) Implement MultiFacets.getAllDims
[ https://issues.apache.org/jira/browse/LUCENE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937087#comment-13937087 ] Shai Erera commented on LUCENE-5525: Looks good! Implement MultiFacets.getAllDims Key: LUCENE-5525 URL: https://issues.apache.org/jira/browse/LUCENE-5525 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7 Reporter: Jose Peleteiro Assignee: Michael McCandless Attachments: LUCENE-5525.patch, LUCENE-5525.patch DrillSideways.DrillSidewaysResult uses Facets when the query does not filter by a facet, but it uses MultiFacets when it does, and MultiFacets implementation is not complete. See: https://github.com/apache/lucene-solr/blob/0b0bc89932622f5bc2c4d74f978178b9ae15c700/lucene/facet/src/java/org/apache/lucene/facet/MultiFacets.java#L67 See http://pastebin.com/5eDbTM2v This code works when DrillDownQuery.add is not called (when there is no facets selected), but it fails with an UnsupportedOperationException. Perhaps I'm not using Facets correctly, but I'm trying to figure it out to upgrade from 4.6.1 by my self as I could not find a documentation other than javadocs for facets. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937095#comment-13937095 ] Han Jiang commented on LUCENE-3069: --- Had to reopen it because jira doesn't permit label change :) Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
On Sun, Mar 16, 2014 at 6:09 AM, Furkan KAMACI furkankam...@gmail.com wrote: I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 +1, Sonar looks really nice! I can be volunteer to integrate Sonar into Lucene/Solr project. Thank you Furkan. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5525) Implement MultiFacets.getAllDims
[ https://issues.apache.org/jira/browse/LUCENE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937097#comment-13937097 ] ASF subversion and git services commented on LUCENE-5525: - Commit 1578042 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1578042 ] LUCENE-5525: implement MultiFacets.getAllDims Implement MultiFacets.getAllDims Key: LUCENE-5525 URL: https://issues.apache.org/jira/browse/LUCENE-5525 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7 Reporter: Jose Peleteiro Assignee: Michael McCandless Attachments: LUCENE-5525.patch, LUCENE-5525.patch DrillSideways.DrillSidewaysResult uses Facets when the query does not filter by a facet, but it uses MultiFacets when it does, and MultiFacets implementation is not complete. See: https://github.com/apache/lucene-solr/blob/0b0bc89932622f5bc2c4d74f978178b9ae15c700/lucene/facet/src/java/org/apache/lucene/facet/MultiFacets.java#L67 See http://pastebin.com/5eDbTM2v This code works when DrillDownQuery.add is not called (when there is no facets selected), but it fails with an UnsupportedOperationException. Perhaps I'm not using Facets correctly, but I'm trying to figure it out to upgrade from 4.6.1 by my self as I could not find a documentation other than javadocs for facets. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5525) Implement MultiFacets.getAllDims
[ https://issues.apache.org/jira/browse/LUCENE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937098#comment-13937098 ] ASF subversion and git services commented on LUCENE-5525: - Commit 1578043 from [~mikemccand] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578043 ] LUCENE-5525: implement MultiFacets.getAllDims Implement MultiFacets.getAllDims Key: LUCENE-5525 URL: https://issues.apache.org/jira/browse/LUCENE-5525 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7 Reporter: Jose Peleteiro Assignee: Michael McCandless Fix For: 4.8, 5.0 Attachments: LUCENE-5525.patch, LUCENE-5525.patch DrillSideways.DrillSidewaysResult uses Facets when the query does not filter by a facet, but it uses MultiFacets when it does, and MultiFacets implementation is not complete. See: https://github.com/apache/lucene-solr/blob/0b0bc89932622f5bc2c4d74f978178b9ae15c700/lucene/facet/src/java/org/apache/lucene/facet/MultiFacets.java#L67 See http://pastebin.com/5eDbTM2v This code works when DrillDownQuery.add is not called (when there is no facets selected), but it fails with an UnsupportedOperationException. Perhaps I'm not using Facets correctly, but I'm trying to figure it out to upgrade from 4.6.1 by my self as I could not find a documentation other than javadocs for facets. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5525) Implement MultiFacets.getAllDims
[ https://issues.apache.org/jira/browse/LUCENE-5525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-5525. Resolution: Fixed Fix Version/s: 5.0 4.8 Implement MultiFacets.getAllDims Key: LUCENE-5525 URL: https://issues.apache.org/jira/browse/LUCENE-5525 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7 Reporter: Jose Peleteiro Assignee: Michael McCandless Fix For: 4.8, 5.0 Attachments: LUCENE-5525.patch, LUCENE-5525.patch DrillSideways.DrillSidewaysResult uses Facets when the query does not filter by a facet, but it uses MultiFacets when it does, and MultiFacets implementation is not complete. See: https://github.com/apache/lucene-solr/blob/0b0bc89932622f5bc2c4d74f978178b9ae15c700/lucene/facet/src/java/org/apache/lucene/facet/MultiFacets.java#L67 See http://pastebin.com/5eDbTM2v This code works when DrillDownQuery.add is not called (when there is no facets selected), but it fails with an UnsupportedOperationException. Perhaps I'm not using Facets correctly, but I'm trying to figure it out to upgrade from 4.6.1 by my self as I could not find a documentation other than javadocs for facets. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3198) Apache Solr to adhere to Apache Project Branding Requirements
[ https://issues.apache.org/jira/browse/SOLR-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937111#comment-13937111 ] Lewis John McGibbney commented on SOLR-3198: [~yo...@apache.org] bq. I'd rather not add TM to the logo... it's not actually required This is not correct. Please see [0]. I think it important for a subproject with the exposure and reputation like Solr to adhere to branding requirements just as every other project should. If there are branding issues, these should also be included in reports sent to board@ and some effort put in to addressing the issues. I'll be happy to take another look into the branding requirements if it would be of any help? [0] http://www.apache.org/foundation/marks/pmcs.html#graphics Apache Solr to adhere to Apache Project Branding Requirements -- Key: SOLR-3198 URL: https://issues.apache.org/jira/browse/SOLR-3198 Project: Solr Issue Type: New Feature Components: documentation Reporter: Lewis John McGibbney Fix For: 4.8 Attachments: SOLR-3198.patch, Solr_tm.png The ASF project branding requirements [0] provide guidelines for projects to follow and adhre to. This is a trivial task, so I'll patch the site and upload it. [0] http://www.apache.org/foundation/marks/pmcs.html -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5528) Add context to AnalyzingInfixSuggester
Michael McCandless created LUCENE-5528: -- Summary: Add context to AnalyzingInfixSuggester Key: LUCENE-5528 URL: https://issues.apache.org/jira/browse/LUCENE-5528 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, 5.0 Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[ https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5528: --- Attachment: LUCENE-5528.patch Patch, I think it's close. I started from Areek's patch on LUCENE-5350, to add context to InputIterator and LookupResult, and then fixed AnalyzingInfixSuggester to index all contexts as StringField, and add MUST clauses to the BooleanQuery at lookup time. I also store the contexts using SSDV field, and return them for each LookupResult. Add context to AnalyzingInfixSuggester -- Key: LUCENE-5528 URL: https://issues.apache.org/jira/browse/LUCENE-5528 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, 5.0 Attachments: LUCENE-5528.patch Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5550) shards.info is not returned in case of short circuited distributed query
[
https://issues.apache.org/jira/browse/SOLR-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-5550:
Attachment: SOLR-5550.patch
Added a test which fails without the patch.
shards.info is not returned in case of short circuited distributed query
Key: SOLR-5550
URL: https://issues.apache.org/jira/browse/SOLR-5550
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5550.patch, SOLR-5550.patch
Distributed queries which are short circuited and executed locally do not
return a shards.info section even when requested.
Steps to reproduce:
# cd solr; ant example; cp -r example example2
# cd example; java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
# cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
# curl
http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
# Add two docs:
{code}
add
doc
field name=ida!1/field
field name=namexyz/field
field name=price2.00/field
/doc
doc
field name=idb!1/field
field name=nameabc/field
field name=price5.00/field
/doc
/add
{code}
# curl
http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
# curl
http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will not return shards.info
# curl
http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will return shards.info
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5604) Remove deprecations caused by httpclient 4.3.x upgrade
[ https://issues.apache.org/jira/browse/SOLR-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937150#comment-13937150 ] Steve Davids commented on SOLR-5604: Sorry about that, I just had a stupid mistake by not adding a newly created class to svn tracking before uploading the patch. -Steve Sent from my iPhone Remove deprecations caused by httpclient 4.3.x upgrade -- Key: SOLR-5604 URL: https://issues.apache.org/jira/browse/SOLR-5604 Project: Solr Issue Type: Improvement Affects Versions: 4.7 Reporter: Shawn Heisey Fix For: 4.8, 5.0 Attachments: SOLR-5604-4x-just-lucene.patch, SOLR-5604.patch SOLR-5590 upgraded httpclient in Solr and Lucene to version 4.3.x. This version deprecates a LOT of classes and methods, recommending that they all be replaced with various methods from the HttpClientBuilder class. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4773) New discovery mode needs to ensure that instanceDir is correct
[ https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-4773. -- Resolution: Fixed Fix Version/s: (was: 4.8) 4.4 5.0 This was fixed a long time ago by SOLR-4790, closing it slipped through the cracks somehow. New discovery mode needs to ensure that instanceDir is correct -- Key: SOLR-4773 URL: https://issues.apache.org/jira/browse/SOLR-4773 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 4.4, 5.0 Reporter: Erick Erickson Assignee: Mark Miller Fix For: 5.0, 4.4 Attachments: SOLR-4773.patch, SOLR-4773.patch Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example fails because we can't find solrconfig. The construction of the instanceDir in SolrCoreDiscoverer constructs a path with an extra solr (e.g. solr/solr/core). I'll attach a patch shortly. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
hİ; Thanks Michael. I will open a Jira issue for it. Thanks; Furkan KAMACI 2014-03-16 13:35 GMT+02:00 Michael McCandless luc...@mikemccandless.com: On Sun, Mar 16, 2014 at 6:09 AM, Furkan KAMACI furkankam...@gmail.com wrote: I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 +1, Sonar looks really nice! I can be volunteer to integrate Sonar into Lucene/Solr project. Thank you Furkan. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
Hi; Here is Apache projects that is analyzed via Sonar: https://analysis.apache.org/all_projects?qualifier=TRK Thanks; Furkan KAMACI 2014-03-16 15:37 GMT+02:00 Furkan KAMACI furkankam...@gmail.com: hİ; Thanks Michael. I will open a Jira issue for it. Thanks; Furkan KAMACI 2014-03-16 13:35 GMT+02:00 Michael McCandless luc...@mikemccandless.com: On Sun, Mar 16, 2014 at 6:09 AM, Furkan KAMACI furkankam...@gmail.com wrote: I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 +1, Sonar looks really nice! I can be volunteer to integrate Sonar into Lucene/Solr project. Thank you Furkan. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Any reason Solr Jira still lists 4.7 as unreleased?
I fixed this last night this morning. Alexandre Rafalovitch wrote I was doing some searching on issues and noticed 4.7 is listed in Unreleased versions. Also, I have a couple of open issues that (possibly due to my mistake) are marked as open but target at 4.7. Was not sure if this is a process that normally lags the actual version release or something to notify. So, I am notifying. Regards, Alex. Personal website: http://www.outerthoughts.com/ LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch - Time is the quality of nature that keeps events from happening all at once. Lately, it doesn't seem to be working. (Anonymous - via GTD book) - To unsubscribe, e-mail: dev-unsubscribe@.apache For additional commands, e-mail: dev-help@.apache - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Any-reason-Solr-Jira-still-lists-4-7-as-unreleased-tp4123605p4124544.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Any reason Solr Jira still lists 4.7 as unreleased?
next time can you please use the option to suppress emails? On Sun, Mar 16, 2014 at 9:42 AM, David Smiley (@MITRE.org) dsmi...@mitre.org wrote: I fixed this last night this morning. Alexandre Rafalovitch wrote I was doing some searching on issues and noticed 4.7 is listed in Unreleased versions. Also, I have a couple of open issues that (possibly due to my mistake) are marked as open but target at 4.7. Was not sure if this is a process that normally lags the actual version release or something to notify. So, I am notifying. Regards, Alex. Personal website: http://www.outerthoughts.com/ LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch - Time is the quality of nature that keeps events from happening all at once. Lately, it doesn't seem to be working. (Anonymous - via GTD book) - To unsubscribe, e-mail: dev-unsubscribe@.apache For additional commands, e-mail: dev-help@.apache - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Any-reason-Solr-Jira-still-lists-4-7-as-unreleased-tp4123605p4124544.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Sorry for JIRA spam
Sorry for all the email spam last night, folks. I Released Lucene Solr 4.7 in JIRA last night. I updated the instructions here https://wiki.apache.org/lucene-java/ReleaseTodo#Update_JIRA to explicitly indicate *not* to have JIRA bump the Fix-version values. ~ David - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Sorry-for-JIRA-spam-tp4124545.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5869) Analyze Lucene/Solr Project Via Sonar
Furkan KAMACI created SOLR-5869: --- Summary: Analyze Lucene/Solr Project Via Sonar Key: SOLR-5869 URL: https://issues.apache.org/jira/browse/SOLR-5869 Project: Solr Issue Type: Task Affects Versions: 4.7, 4.6.1 Reporter: Furkan KAMACI Fix For: 4.8 Sonar is an open platform used to manage code quality. You can check it from here: http://www.sonarqube.org/ It would be nice if we analyze Lucene/Solr project with Sonar. You can find a list of Apache Projects that's analyzed via Sonar: https://analysis.apache.org/all_projects?qualifier=TRK We should add our project to Sonar instance available at Apache -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5869) Analyze Lucene/Solr Project Via Sonar
[ https://issues.apache.org/jira/browse/SOLR-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937165#comment-13937165 ] Furkan KAMACI commented on SOLR-5869: - I'll implement a patch for this issue. Analyze Lucene/Solr Project Via Sonar - Key: SOLR-5869 URL: https://issues.apache.org/jira/browse/SOLR-5869 Project: Solr Issue Type: Task Affects Versions: 4.6.1, 4.7 Reporter: Furkan KAMACI Fix For: 4.8 Sonar is an open platform used to manage code quality. You can check it from here: http://www.sonarqube.org/ It would be nice if we analyze Lucene/Solr project with Sonar. You can find a list of Apache Projects that's analyzed via Sonar: https://analysis.apache.org/all_projects?qualifier=TRK We should add our project to Sonar instance available at Apache -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
JIRA SPAM HELP IN GMAIL
Forgive the caps... I figured it might show up better amongst the flood of JIRA messages. If you're a gmail user and want to clean up your inbox from the latest flood: - go to settings, then the general tab, and select conversation view off - do a search for Fix Version/s: (was: 4.7)(use the quotes!) - select all, then press select all messages that match this search - archive or delete the messages - return to your inbox and the messages should be gone (the search view will continue displaying the messages even after they have been archived) - go back to settings and restore conversation view on if that's what you started with Any gmail gurus out there know how to select messages (as opposed to entire conversations) when in conversation mode? (basically, any way to skip step #1?) -Yonik http://heliosearch.org - solve Solr GC pauses with off-heap filters and fieldcache - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937169#comment-13937169 ] Erick Erickson commented on LUCENE-1486: OK, this seems like it's completely obsolete, any objections to closing? Should we raise Nikhil Chhaochharia's comment in a new JIRA to test at least? Wildcards, ORs etc inside Phrase queries Key: LUCENE-1486 URL: https://issues.apache.org/jira/browse/LUCENE-1486 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 2.4 Reporter: Mark Harwood Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch, TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch, junit_complex_phrase_qp_07_22_2009.patch An extension to the default QueryParser that overrides the parsing of PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries. The implementation feels a little hacky - this is arguably better handled in QueryParser itself. This works as a proof of concept for much of the query parser syntax. Examples from the Junit test include: checkMatches(\j* smyth~\, 1,2); //wildcards and fuzzies are OK in phrases checkMatches(\(jo* -john) smith\, 2); // boolean logic works checkMatches(\jo* smith\~2, 1,2,3); // position logic works. checkBadQuery(\jo* id:1 smith\); //mixing fields in a phrase is bad checkBadQuery(\jo* \smith\ \); //phrases inside phrases is bad checkBadQuery(\jo* [sma TO smZ]\ \); //range queries inside phrases not supported Code plus Junit test to follow... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5550) shards.info is not returned in case of short circuited distributed query
[
https://issues.apache.org/jira/browse/SOLR-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937172#comment-13937172
]
ASF subversion and git services commented on SOLR-5550:
---
Commit 1578078 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1578078 ]
SOLR-5550: shards.info is not returned by a short circuited distributed query
shards.info is not returned in case of short circuited distributed query
Key: SOLR-5550
URL: https://issues.apache.org/jira/browse/SOLR-5550
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5550.patch, SOLR-5550.patch
Distributed queries which are short circuited and executed locally do not
return a shards.info section even when requested.
Steps to reproduce:
# cd solr; ant example; cp -r example example2
# cd example; java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
# cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
# curl
http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
# Add two docs:
{code}
add
doc
field name=ida!1/field
field name=namexyz/field
field name=price2.00/field
/doc
doc
field name=idb!1/field
field name=nameabc/field
field name=price5.00/field
/doc
/add
{code}
# curl
http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
# curl
http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will not return shards.info
# curl
http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will return shards.info
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5550) shards.info is not returned in case of short circuited distributed query
[
https://issues.apache.org/jira/browse/SOLR-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937174#comment-13937174
]
ASF subversion and git services commented on SOLR-5550:
---
Commit 1578083 from sha...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1578083 ]
SOLR-5550: shards.info is not returned by a short circuited distributed query
shards.info is not returned in case of short circuited distributed query
Key: SOLR-5550
URL: https://issues.apache.org/jira/browse/SOLR-5550
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5550.patch, SOLR-5550.patch
Distributed queries which are short circuited and executed locally do not
return a shards.info section even when requested.
Steps to reproduce:
# cd solr; ant example; cp -r example example2
# cd example; java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
# cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
# curl
http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
# Add two docs:
{code}
add
doc
field name=ida!1/field
field name=namexyz/field
field name=price2.00/field
/doc
doc
field name=idb!1/field
field name=nameabc/field
field name=price5.00/field
/doc
/add
{code}
# curl
http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
# curl
http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will not return shards.info
# curl
http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will return shards.info
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5550) shards.info is not returned in case of short circuited distributed query
[
https://issues.apache.org/jira/browse/SOLR-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-5550.
-
Resolution: Fixed
Thanks Tim!
shards.info is not returned in case of short circuited distributed query
Key: SOLR-5550
URL: https://issues.apache.org/jira/browse/SOLR-5550
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5550.patch, SOLR-5550.patch
Distributed queries which are short circuited and executed locally do not
return a shards.info section even when requested.
Steps to reproduce:
# cd solr; ant example; cp -r example example2
# cd example; java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
# cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
# curl
http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
# Add two docs:
{code}
add
doc
field name=ida!1/field
field name=namexyz/field
field name=price2.00/field
/doc
doc
field name=idb!1/field
field name=nameabc/field
field name=price5.00/field
/doc
/add
{code}
# curl
http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
# curl
http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will not return shards.info
# curl
http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will return shards.info
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5550) shards.info is not returned in case of short circuited distributed query
[
https://issues.apache.org/jira/browse/SOLR-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937177#comment-13937177
]
Shalin Shekhar Mangar commented on SOLR-5550:
-
Oh, just fyi, I made one change before committing the patch. I reduced
shardCount to 4 from 8. No need to spin up extra replicas here.
shards.info is not returned in case of short circuited distributed query
Key: SOLR-5550
URL: https://issues.apache.org/jira/browse/SOLR-5550
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.6
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5550.patch, SOLR-5550.patch
Distributed queries which are short circuited and executed locally do not
return a shards.info section even when requested.
Steps to reproduce:
# cd solr; ant example; cp -r example example2
# cd example; java -Dbootstrap_confdir=./solr/collection1/conf
-Dcollection.configName=conf1 -DzkRun -DnumShards=2 -jar start.jar
# cd example2; java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
# curl
http://localhost:8983/solr/admin/collections?action=CREATEcollection=test1name=test1numShards=2collection.configName=conf1maxShardsPerNode=3
# Add two docs:
{code}
add
doc
field name=ida!1/field
field name=namexyz/field
field name=price2.00/field
/doc
doc
field name=idb!1/field
field name=nameabc/field
field name=price5.00/field
/doc
/add
{code}
# curl
http://localhost:8983/admin/cores?name=test1_shard2_replica2collection=test1shard=shard2
# curl
http://localhost:8983/solr/test1_shard2_replica1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will not return shards.info
# curl
http://localhost:7574/solr/test1/select?_route_=b!fl=*start=0q=*:*shards.info=truecollection=test1rows=10
# The above will return shards.info
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Use of fix version
all issues with Unresolved Resolution and fixVersion of the release you just made, and do a bulk change to the fixVersion to be both the trunk version and the next version on the branch you just released from. Uncheck the box that says send an email for these changes. It seems to me that a lot of issues are indicated to be fixed in the next dot release when they are in fact very unlikely to be fixed in the next dot release - or necessarily in trunk for that matter. Could someone explain the rationale? I mean, shouldn't Fix Version: 4.8 mean that there is a very high likelihood of resolution in 4.8, rather than mere wishful thinking or bulk bureaucratic assignment? I mean, wouldn't it make more sense to use a more agile methodology, with most issues being in an unassigned backlog, and being very selective what is targeted for the current sprint/next dot release? Ditto for trunk - shouldn't it be more selective so that we can see how close we are to finishing the high priority issues needed for a trunk release? I mean, how useful is fix version in its current form? And maybe there needs to be special formatting to highlight the importance of Uncheck the box that says send an email for these changes., although the omission of that step did highlight the main issue I mentioned. -- Jack Krupansky -Original Message- From: Apache Wiki Sent: Sunday, March 16, 2014 9:06 AM To: Apache Wiki Subject: [Lucene-java Wiki] Update of ReleaseTodo by DavidSmiley Dear Wiki user, You have subscribed to a wiki page or wiki category on Lucene-java Wiki for change notification. The ReleaseTodo page has been changed by DavidSmiley: https://wiki.apache.org/lucene-java/ReleaseTodo?action=diffrev1=165rev2=166 Comment: Releasing in JIRA requires more choosing the Release option. And clarify to not transition issues then. = Post-release = == Update JIRA == - 1. Go to the JIRA Manage Versions Administration pages (https://issues.apache.org/jira/plugins/servlet/project-config/LUCENE/versions and https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/versions), click on the release date field for the version you just released, put in the release date, and then click the Update button. + 1. Go to the JIRA Manage Versions Administration pages (https://issues.apache.org/jira/plugins/servlet/project-config/LUCENE/versions and https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/versions). Next to the version you'll release, click the gear pop-up menu icon and choose Release. It will ask you for the release date -- enter it. It will give the option of transitioning issues marked fix-for the released version to the next version, but do '''not''' do this as it will send an email for each issue -- we'll address that separately. - 1. Go to JIRA search in both Solr and Lucene and find all issues that were fixed in the release you just made, whose Status is Resolved, and do a bulk change to close all of these issues. Uncheck the box that says send an email for these changes. + 1. Go to JIRA search in both Solr and Lucene and find all issues that were fixed in the release you just made, whose Status is Resolved, and do a bulk change to close all of these issues (this is a workflow transition task). Uncheck the box that says send an email for these changes. 1. Do another JIRA search in both Solr and Lucene to find all issues with Unresolved Resolution and fixVersion of the release you just made, and do a bulk change to the fixVersion to be both the trunk version and the next version on the branch you just released from. Uncheck the box that says send an email for these changes. == Don't mirror old releases == - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Use of fix version
Jack Krupansky-2 wrote And maybe there needs to be special formatting to highlight the importance of Uncheck the box that says send an email for these changes., although the omission of that step did highlight the main issue I mentioned. My error was not neglecting to see that, it was letting JIRA bump the fix-for versions as part of choosing Release menu next to the version in the version screen. So I added explicit instructions on the choice on the wiki. Sorry again. To your larger point of fix-for versions... we can't stop users using them how we might want them to be used, so there's little benefit in trying to have it reflect some particular meaning (i.e. it really really will be likely to be done by fix-for version). ~ David - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Use-of-fix-version-tp4124560p4124561.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5838) Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
[
https://issues.apache.org/jira/browse/SOLR-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937180#comment-13937180
]
ASF subversion and git services commented on SOLR-5838:
---
Commit 1578089 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1578089 ]
SOLR-5838: Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Key: SOLR-5838
URL: https://issues.apache.org/jira/browse/SOLR-5838
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5838.patch
getRelativeSolrHomePath method at AbstractFullDistribZkTestBase has a control
like that:
{code}
if (base.startsWith(.));
base.replaceFirst(\\., new File(.).getName());
{code}
if statement does nothing and result of replaceFirst is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5838) Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
[
https://issues.apache.org/jira/browse/SOLR-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937181#comment-13937181
]
ASF subversion and git services commented on SOLR-5838:
---
Commit 1578090 from sha...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1578090 ]
SOLR-5838: Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Key: SOLR-5838
URL: https://issues.apache.org/jira/browse/SOLR-5838
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5838.patch
getRelativeSolrHomePath method at AbstractFullDistribZkTestBase has a control
like that:
{code}
if (base.startsWith(.));
base.replaceFirst(\\., new File(.).getName());
{code}
if statement does nothing and result of replaceFirst is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5529) Spatial: Small optimization searching on indexed non-point shapes
David Smiley created LUCENE-5529: Summary: Spatial: Small optimization searching on indexed non-point shapes Key: LUCENE-5529 URL: https://issues.apache.org/jira/browse/LUCENE-5529 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.8 When searching for indexed non-point shapes (such as polygons), there are redundant cells which can be skipped at the bottom detail level of the search. This won't be a problem once LUCENE-4942 is fixed since there then won't be any but it's easy to fix now. This affects all predicates RecursivePrefixTreeStrategy uses except Contains. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5838) Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
[
https://issues.apache.org/jira/browse/SOLR-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-5838.
-
Resolution: Fixed
Assignee: Shalin Shekhar Mangar
Thanks Furkan!
Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Key: SOLR-5838
URL: https://issues.apache.org/jira/browse/SOLR-5838
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5838.patch
getRelativeSolrHomePath method at AbstractFullDistribZkTestBase has a control
like that:
{code}
if (base.startsWith(.));
base.replaceFirst(\\., new File(.).getName());
{code}
if statement does nothing and result of replaceFirst is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: JIRA SPAM HELP IN GMAIL
Hi Yonik; I use Gmail too and I've divided dev e-mails with filters and assigned them labels. I have dev(includes everything), dev-jira, and dev-filtered (does not include jira e-mails). Also you can filter for VOTE, CONF, JENKINS or etc too. So it is easy to focus on what you want. Thanks; Furkan KAMACI 2014-03-16 15:51 GMT+02:00 Yonik Seeley yo...@heliosearch.com: Forgive the caps... I figured it might show up better amongst the flood of JIRA messages. If you're a gmail user and want to clean up your inbox from the latest flood: - go to settings, then the general tab, and select conversation view off - do a search for Fix Version/s: (was: 4.7)(use the quotes!) - select all, then press select all messages that match this search - archive or delete the messages - return to your inbox and the messages should be gone (the search view will continue displaying the messages even after they have been archived) - go back to settings and restore conversation view on if that's what you started with Any gmail gurus out there know how to select messages (as opposed to entire conversations) when in conversation mode? (basically, any way to skip step #1?) -Yonik http://heliosearch.org - solve Solr GC pauses with off-heap filters and fieldcache - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5529) Spatial: Small optimization searching on indexed non-point shapes
[ https://issues.apache.org/jira/browse/LUCENE-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-5529: - Attachment: LUCENE-5529_Skip_redundant_non-point_scanned_cells.patch In my testing this resulted in 1-3% increase on circles; it'll likely be greater for polygon query shapes where it's more expensive to do an intersection test. The patch includes unrelated TODOs on spatial classes for things I want to get to in the near future. It also includes a small change to query equality (equals hashcode) such that a tuning parameter isn't included because it doesn't change the semantics of the query. I'll commit this Monday. Spatial: Small optimization searching on indexed non-point shapes - Key: LUCENE-5529 URL: https://issues.apache.org/jira/browse/LUCENE-5529 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.8 Attachments: LUCENE-5529_Skip_redundant_non-point_scanned_cells.patch When searching for indexed non-point shapes (such as polygons), there are redundant cells which can be skipped at the bottom detail level of the search. This won't be a problem once LUCENE-4942 is fixed since there then won't be any but it's easy to fix now. This affects all predicates RecursivePrefixTreeStrategy uses except Contains. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5868) HttpClient should be configured to use ALLOW_ALL_HOSTNAME hostname verifier to simplify SSL setup
[ https://issues.apache.org/jira/browse/SOLR-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-5868: --- Attachment: SOLR-5868.patch Patch attached to work in the current form of the trunk (non HttpClientBuilder version). HttpClient should be configured to use ALLOW_ALL_HOSTNAME hostname verifier to simplify SSL setup - Key: SOLR-5868 URL: https://issues.apache.org/jira/browse/SOLR-5868 Project: Solr Issue Type: Improvement Affects Versions: 4.7 Reporter: Steve Davids Fix For: 4.8 Attachments: SOLR-5868.patch The default HttpClient hostname verifier is the BROWSER_COMPATIBLE_HOSTNAME_VERIFIER which verifies the hostname that is being connected to matches the hostname presented within the certificate. This is meant to protect clients that are making external requests out across the internet, but requests within the the SOLR cluster should be trusted and can be relaxed to simplify the SSL/certificate setup process. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: JIRA SPAM HELP IN GMAIL
On Sun, Mar 16, 2014 at 10:50 AM, Furkan KAMACI furkankam...@gmail.com wrote: I use Gmail too and I've divided dev e-mails with filters and assigned them labels. I have dev(includes everything), dev-jira, and dev-filtered (does not include jira e-mails). Also you can filter for VOTE, CONF, JENKINS or etc too. So it is easy to focus on what you want. Yeah, I already make heavy use of filters. This was really about removing a ton of emails that had no information content though (I normally do want to see JIRA updates otherwise). -Yonik http://heliosearch.org - solve Solr GC pauses with off-heap filters and fieldcache - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: SolrCloud and https
Just to give everyone an update - I upgraded our SolrCloud cluster from
4.3.1 (manually patched for SSL) - 4.7 and have ran into a couple of
issues, though I have created Jira tickets for them and some have already
been committed.
1. The update shard handler wasn't using the system properties to pick
up the javax.net.ssl.* configuration
(SOLR-5866https://issues.apache.org/jira/browse/SOLR-5866
)
2. Overseer collector doesn't use the right scheme in a small use case,
only came across this perusing the code but will impact some select admin
calls (SOLR-5867 https://issues.apache.org/jira/browse/SOLR-5867)
3. Wiring up a custom HttpClientConfigurer has proven to be a bit more
challenging as the HttpClientUtil needs to set the new configurer before
Solr begins to be constructed, so I was left with options such as setting
up a webapp-listener in the webdefaults.xml to get a hook in before the
Solr servlet gets loaded. If there is a better way to achieve this please
let us know, I thought there *must* be a better way but it eluded me. For
simplicity sake I ended up just patching in my custom HttpClientConfigurer
into the war itself.
After further contemplation I thought Solr should be lenient in which
certificates are acceptable to communicate within the cluster itself
instead of the default HttpClient configuration that is more strict for
communication to external sources. With that in mind I created a ticket to
set the default host name verifier to allow all hostnames
(SOLR-5868https://issues.apache.org/jira/browse/SOLR-5868)
and we may consider allowing self-signed certs as well. With those changes
the need to wire up a custom HttpClientConfigurer becomes greatly reduced.
To get 4.7 up and running in it's current fashion, you can use the
following custom HttpClientConfigurer (also fixes problem with SOLR-5866):
https://gist.github.com/sdavids13/9577027
-Steve
On Thu, Mar 13, 2014 at 10:31 PM, Steve Davids sdav...@gmail.com wrote:
Glad to hear it works for you! It would be nice if we could upload the
json file via the zk bootstrapping, it sure would make it a bit simpler.
-Steve
On Mar 13, 2014, at 10:19 PM, Erick Erickson erickerick...@gmail.com
wrote:
Darn Windows. It turns out that this works (thanks Steve!)
./zkcli.sh -zkhost localhost:9983 -cmd put /clusterprops.json
'{urlScheme:https}'
but only if you escape the double quotes and remove the ticks, as:
./zkcli.sh -zkhost localhost:9983 -cmd put /clusterprops.json
{\urlScheme\:\https\}
Otherwise clusterprops.json contains the ticks as well.
Got it working though
On Thu, Mar 13, 2014 at 9:43 AM, Erick Erickson erickerick...@gmail.com
wrote:
I was thinking about that but haven't had a chance to catch my breath.
Thanks for letting me know where the link is...
Erick
On Thu, Mar 13, 2014 at 9:08 AM, Cassandra Targett
casstarg...@gmail.com wrote:
This needs to also make its way into the Solr Ref Guide - stuff
documented
on the wiki doesn't automatically get into the Solr Reference Guide
without
human intervention.
There is an issue already to document this in the guide, so if you do
add
something to the Solr Wiki, please add a link to the page to
https://issues.apache.org/jira/browse/SOLR-5757 so it can be
officially
documented.
Thanks,
Cassandra
On Wed, Mar 12, 2014 at 7:19 PM, Erick Erickson
erickerick...@gmail.com
wrote:
Steve:
It would be a great service if you were willing to document this on
the Wiki. If you don't already have contributor rights, just create a
logon on the Wiki, send us your logon ID and we'll add you to the
approved editors list.
A bit of background: We used to let anyone edit the Wiki, but then
started getting hit with a billion spam pages so had to lock it down.
As long as we're convinced it's a real person asking for edit rights,
they're freely granted!
Best,
Erick
On Wed, Mar 12, 2014 at 8:15 PM, Steve Davids sdav...@gmail.com
wrote:
I will be upgrading my SolrCloud cluster at work in a couple of days
(hand
patched former builds) will let everyone know if there are any other
gothchyas. I know depending on different cases the need to bundle
your
own
HttpClientConfigurer to use the AllowAllHostnameVerifier (if using a
single
cert for all instances) or to add the TrustedSelfSignedStrategy if
using
two-way SSL w/ self-signed certs.
-Steve
On Mar 12, 2014, at 8:05 PM, Erick Erickson erickerick...@gmail.com
wrote:
Steve:
Thanks, I confess confusion about all things HTTPS. I'll turn this
over to the people who _do_ know about it in the morning, this is a
great help in that it tells us where to look.
I smell a Wiki page coming
Erick
On Wed, Mar 12, 2014 at 7:47 PM, Steve Davids sdav...@gmail.com
wrote:
Hi Eric,
Unfortunately the only working example is in the unit-tests. What
have
you
[jira] [Commented] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.
[ https://issues.apache.org/jira/browse/LUCENE-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937196#comment-13937196 ] Erick Erickson commented on LUCENE-3758: Just to make sure I understand Dimitry's comment about the # operator. I don't see anything in this patch on a quick look that references a new operator, so that's a separate issue, correct? I see in the related SOLR-1604 patch the ability to specify inOrder=true|false as a local parameter, so this functionality is available at that level. Frankly, I'd rather not introduce a new operator at this stage, let's get the underlying functionality in place and treat any new operators as a separate issue if we add one it at all. Any responses to the comment by [~rcmuir]? My quick response is that I've seen use-cases like this: Find all the variants of john anderson, including 'jonathan anderson', 'jon ivan gregory anderson' but not 'eric anderson and jonathan jones' . Contrived a bit, but you get the idea. Specifying slop doesn't allow this case, but slop with specified order does. I'm going to be committing this this, along with SOLR-1604 today unless there are objections. The patch doesn't change current behavior so it seems pretty safe. Allow the ComplexPhraseQueryParser to search order or un-order proximity queries. - Key: LUCENE-3758 URL: https://issues.apache.org/jira/browse/LUCENE-3758 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.0-ALPHA Reporter: Tomás Fernández Löbbe Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: LUCENE-3758.patch, LUCENE-3758.patch The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder value hardcoded to true. This could be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
Ahmet Arslan created LUCENE-5530:
Summary: ComplexPhraseQueryParser throws ParseException for
fielded queries
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Fix For: 4.8
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937204#comment-13937204 ] Ahmet Arslan commented on LUCENE-1486: -- bq. Should we raise Nikhil Chhaochharia's comment in a new JIRA to test at least? I created LUCENE-5530 for fielded query support. Wildcards, ORs etc inside Phrase queries Key: LUCENE-1486 URL: https://issues.apache.org/jira/browse/LUCENE-1486 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 2.4 Reporter: Mark Harwood Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch, TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch, junit_complex_phrase_qp_07_22_2009.patch An extension to the default QueryParser that overrides the parsing of PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries. The implementation feels a little hacky - this is arguably better handled in QueryParser itself. This works as a proof of concept for much of the query parser syntax. Examples from the Junit test include: checkMatches(\j* smyth~\, 1,2); //wildcards and fuzzies are OK in phrases checkMatches(\(jo* -john) smith\, 2); // boolean logic works checkMatches(\jo* smith\~2, 1,2,3); // position logic works. checkBadQuery(\jo* id:1 smith\); //mixing fields in a phrase is bad checkBadQuery(\jo* \smith\ \); //phrases inside phrases is bad checkBadQuery(\jo* [sma TO smZ]\ \); //range queries inside phrases not supported Code plus Junit test to follow... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937207#comment-13937207 ] Erick Erickson commented on LUCENE-1486: What about the stopwords bit? yet another JIRA? Wildcards, ORs etc inside Phrase queries Key: LUCENE-1486 URL: https://issues.apache.org/jira/browse/LUCENE-1486 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 2.4 Reporter: Mark Harwood Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch, TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch, junit_complex_phrase_qp_07_22_2009.patch An extension to the default QueryParser that overrides the parsing of PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries. The implementation feels a little hacky - this is arguably better handled in QueryParser itself. This works as a proof of concept for much of the query parser syntax. Examples from the Junit test include: checkMatches(\j* smyth~\, 1,2); //wildcards and fuzzies are OK in phrases checkMatches(\(jo* -john) smith\, 2); // boolean logic works checkMatches(\jo* smith\~2, 1,2,3); // position logic works. checkBadQuery(\jo* id:1 smith\); //mixing fields in a phrase is bad checkBadQuery(\jo* \smith\ \); //phrases inside phrases is bad checkBadQuery(\jo* [sma TO smZ]\ \); //range queries inside phrases not supported Code plus Junit test to follow... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.
[ https://issues.apache.org/jira/browse/LUCENE-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated LUCENE-3758: --- Attachment: LUCENE-3758.patch Ahmet's patch plus entry in CHANGES.txt Allow the ComplexPhraseQueryParser to search order or un-order proximity queries. - Key: LUCENE-3758 URL: https://issues.apache.org/jira/browse/LUCENE-3758 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.0-ALPHA Reporter: Tomás Fernández Löbbe Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: LUCENE-3758.patch, LUCENE-3758.patch, LUCENE-3758.patch The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder value hardcoded to true. This could be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3578) TestSort testParallelMultiSort reproducible seed failure
[
https://issues.apache.org/jira/browse/LUCENE-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937214#comment-13937214
]
ASF subversion and git services commented on LUCENE-3578:
-
Commit 1578113 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1578113 ]
Fix for LUCENE-3578, the ability to specify order for complex phrase queries
TestSort testParallelMultiSort reproducible seed failure
Key: LUCENE-3578
URL: https://issues.apache.org/jira/browse/LUCENE-3578
Project: Lucene - Core
Issue Type: Bug
Reporter: selckin
Assignee: Michael McCandless
Fix For: 4.0-ALPHA
trunk r1202157
{code}
[junit] Testsuite: org.apache.lucene.search.TestSort
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.978 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestSort
-Dtestmethod=testParallelMultiSort
-Dtests.seed=-2996f3e0f5d118c2:32c8e62dd9611f63:7a90f44586ae8263
-Dargs=-Dfile.encoding=UTF-8
[junit] WARNING: test method: 'testParallelMultiSort' left thread
running: Thread[pool-1-thread-1,5,main]
[junit] WARNING: test method: 'testParallelMultiSort' left thread
running: Thread[pool-1-thread-2,5,main]
[junit] WARNING: test method: 'testParallelMultiSort' left thread
running: Thread[pool-1-thread-3,5,main]
[junit] NOTE: test params are: codec=Lucene40:
{short=Lucene40(minBlockSize=98 maxBlockSize=214),
contents=PostingsFormat(name=MockSep), byte=PostingsFormat(name=SimpleText),
int=Pulsing40(freqCutoff=4 minBlockSize=58 maxBlockSize=186),
string=PostingsFormat(name=NestedPulsing), i18n=Lucene40(minBlockSize=98
maxBlockSize=214), long=PostingsFormat(name=Memory),
double=Pulsing40(freqCutoff=4 minBlockSize=58 maxBlockSize=186),
parser=MockVariableIntBlock(baseBlockSize=88), float=Lucene40(minBlockSize=98
maxBlockSize=214), custom=PostingsFormat(name=MockRandom)},
sim=RandomSimilarityProvider(queryNorm=false,coord=false):
{short=BM25(k1=1.2,b=0.75), tracer=DFR I(ne)B2, byte=DFR I(ne)B3(800.0),
contents=IB LL-LZ(0.3), int=DFR I(n)BZ(0.3), string=IB LL-D3(800.0), i18n=DFR
GB2, double=DFR I(ne)B2, long=DFR GB1, parser=DFR GL2,
float=BM25(k1=1.2,b=0.75), custom=DFR I(ne)Z(0.3)}, locale=ga_IE,
timezone=America/Louisville
[junit] NOTE: all tests run in this JVM:
[junit] [TestSort]
[junit] NOTE: Linux 3.0.6-gentoo amd64/Sun Microsystems Inc. 1.6.0_29
(64-bit)/cpus=8,threads=4,free=78022136,total=125632512
[junit] - ---
[junit] Testcase:
testParallelMultiSort(org.apache.lucene.search.TestSort): FAILED
[junit] expected:[ZJ]I but was:[JZ]I
[junit] junit.framework.AssertionFailedError: expected:[ZJ]I but
was:[JZ]I
[junit] at
org.apache.lucene.search.TestSort.assertMatches(TestSort.java:1245)
[junit] at
org.apache.lucene.search.TestSort.assertMatches(TestSort.java:1216)
[junit] at
org.apache.lucene.search.TestSort.runMultiSorts(TestSort.java:1202)
[junit] at
org.apache.lucene.search.TestSort.testParallelMultiSort(TestSort.java:855)
[junit] at
org.apache.lucene.util.LuceneTestCase$3$1.evaluate(LuceneTestCase.java:523)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:149)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:51)
[junit]
[junit]
[junit] Test org.apache.lucene.search.TestSort FAILED
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
[
https://issues.apache.org/jira/browse/LUCENE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ahmet Arslan updated LUCENE-5530:
-
Attachment: LUCENE-5530.patch
Bring fielded query support by changing the visibility of field in the
QueryParserBase class from package-private to protected.
ComplexPhraseQueryParser throws ParseException for fielded queries
---
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Labels: complexPhrase
Fix For: 4.8
Attachments: LUCENE-5530.patch
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-1604: - Attachment: SOLR-1604.patch Added entry to CHANGES.txt for Solr Wildcards, ORs etc inside Phrase Queries Key: SOLR-1604 URL: https://issues.apache.org/jira/browse/SOLR-1604 Project: Solr Issue Type: Improvement Components: query parsers, search Affects Versions: 1.4 Reporter: Ahmet Arslan Assignee: Erick Erickson Priority: Minor Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4834) Surround QParser should enable query text analysis
[
https://issues.apache.org/jira/browse/SOLR-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937223#comment-13937223
]
Ahmet Arslan commented on SOLR-4834:
Hey [~isaachebsh], did you check LUCENE-5205 ? [~paul.elsc...@xs4all.nl] says :
bq. I think this has a lot more possibilities than the surround parser. So much
more that this might actually replace the surround parser.
Surround QParser should enable query text analysis
--
Key: SOLR-4834
URL: https://issues.apache.org/jira/browse/SOLR-4834
Project: Solr
Issue Type: Improvement
Components: query parsers
Affects Versions: 4.3
Reporter: Isaac Hebsh
Labels: analysis, qparserplugin, surround
Fix For: 4.8
When using surround query parser, the query terms are not being analyzed. The
basic example is lower case, of course. This is probably an intended
behaviour, not a bug.
I suggest one more query parameter, which determines whether to do analysis
or not. something like this:
{code}
_query_:{!surround df=myfield analyze=true}SpinPoint 7n GB18030
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937228#comment-13937228 ] Ahmet Arslan commented on LUCENE-1486: -- bq. What about the stopwords bit? yet another JIRA? There is no patch/solution for that in ComplexPhraseQueryParser. Tim says about the topic : bq. The root of this problem is that SpanNearQuery has no good way to handle stopwords in a way analagous to PhraseQuery. I suggested [~nikhil500] to use a modified StopwordFilter ( I sent the filter to him offlist) that does not remove but instead reduces given stop words to an impossible token. the = ImpossibleToken a = ImpossibleToken for = ImpossibleToken I think we don't need a jira for this functionality but we can document this as limitation and workaround for this. Wildcards, ORs etc inside Phrase queries Key: LUCENE-1486 URL: https://issues.apache.org/jira/browse/LUCENE-1486 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 2.4 Reporter: Mark Harwood Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch, TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch, junit_complex_phrase_qp_07_22_2009.patch An extension to the default QueryParser that overrides the parsing of PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries. The implementation feels a little hacky - this is arguably better handled in QueryParser itself. This works as a proof of concept for much of the query parser syntax. Examples from the Junit test include: checkMatches(\j* smyth~\, 1,2); //wildcards and fuzzies are OK in phrases checkMatches(\(jo* -john) smith\, 2); // boolean logic works checkMatches(\jo* smith\~2, 1,2,3); // position logic works. checkBadQuery(\jo* id:1 smith\); //mixing fields in a phrase is bad checkBadQuery(\jo* \smith\ \); //phrases inside phrases is bad checkBadQuery(\jo* [sma TO smZ]\ \); //range queries inside phrases not supported Code plus Junit test to follow... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937235#comment-13937235 ] Ahmet Arslan commented on LUCENE-1486: -- One thing is , [~tomasflobbe] has reported one problem in his [comment|https://issues.apache.org/jira/browse/LUCENE-1486?focusedCommentId=13202409page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13202409] . And he has provided a solution too. Its about fred* kind of queries. There is only one term inside quotes. Wildcards, ORs etc inside Phrase queries Key: LUCENE-1486 URL: https://issues.apache.org/jira/browse/LUCENE-1486 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 2.4 Reporter: Mark Harwood Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch, TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch, junit_complex_phrase_qp_07_22_2009.patch An extension to the default QueryParser that overrides the parsing of PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries. The implementation feels a little hacky - this is arguably better handled in QueryParser itself. This works as a proof of concept for much of the query parser syntax. Examples from the Junit test include: checkMatches(\j* smyth~\, 1,2); //wildcards and fuzzies are OK in phrases checkMatches(\(jo* -john) smith\, 2); // boolean logic works checkMatches(\jo* smith\~2, 1,2,3); // position logic works. checkBadQuery(\jo* id:1 smith\); //mixing fields in a phrase is bad checkBadQuery(\jo* \smith\ \); //phrases inside phrases is bad checkBadQuery(\jo* [sma TO smZ]\ \); //range queries inside phrases not supported Code plus Junit test to follow... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5498) Allow DIH to report its state to ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-5498: --- Assignee: Shalin Shekhar Mangar Allow DIH to report its state to ZooKeeper -- Key: SOLR-5498 URL: https://issues.apache.org/jira/browse/SOLR-5498 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 4.5 Reporter: Rafał Kuć Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 4.8 Attachments: SOLR-5498.patch, SOLR-5498_version.patch I thought it may be good to be able for DIH to be fully controllable by Solr in SolrCloud. So when once instance fails another could be automatically started and so on. This issue is the first small step there - it makes SolrCloud report DIH state to ZooKeeper once it is started and remove its state once it is stopped or indexing job failed. In non-cloud mode that functionality is not used. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4777) Handle SliceState in the Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-4777: --- Assignee: Shalin Shekhar Mangar Handle SliceState in the Admin UI - Key: SOLR-4777 URL: https://issues.apache.org/jira/browse/SOLR-4777 Project: Solr Issue Type: Improvement Components: SolrCloud, web gui Affects Versions: 4.3 Reporter: Anshum Gupta Assignee: Shalin Shekhar Mangar Fix For: 4.8 Attachments: SOLR-4777.patch, SOLR-4777.patch The Solr admin UI as of now does take Slice state into account. We need to have that differentiated. There are three states: # The default is active # construction (used during shard splitting for new sub shards), # 'recovery' (state is changed from construction to recovery once split is complete and we are waiting for sub-shard replicas to recover from their respective leaders), and # inactive - the parent shard is set to this state after split is complete A slice/shard which is inactive will not accept traffic (i.e. it will re-route traffic to sub shards) even though the nodes inside this shard show up as green. We should show the inactive shards in a different color to highlight this behavior. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5376) Add a demo search server
[ https://issues.apache.org/jira/browse/LUCENE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937242#comment-13937242 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1578132 from [~mikemccand] in branch 'dev/branches/lucene5376_2' [ https://svn.apache.org/r1578132 ] LUCENE-5376: make new branch Add a demo search server Key: LUCENE-5376 URL: https://issues.apache.org/jira/browse/LUCENE-5376 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: lucene-demo-server.tgz I think it'd be useful to have a demo search server for Lucene. Rather than being fully featured, like Solr, it would be minimal, just wrapping the existing Lucene modules to show how you can make use of these features in a server setting. The purpose is to demonstrate how one can build a minimal search server on top of APIs like SearchManager, SearcherLifetimeManager, etc. This is also useful for finding rough edges / issues in Lucene's APIs that make building a server unnecessarily hard. I don't think it should have back compatibility promises (except Lucene's index back compatibility), so it's free to improve as Lucene's APIs change. As a starting point, I'll post what I built for the eating your own dog food search app for Lucene's Solr's jira issues http://jirasearch.mikemccandless.com (blog: http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It uses Netty to expose basic indexing searching APIs via JSON, but it's very rough (lots nocommits). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5376) Add a demo search server
[ https://issues.apache.org/jira/browse/LUCENE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937244#comment-13937244 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1578133 from [~mikemccand] in branch 'dev/branches/lucene5376_2' [ https://svn.apache.org/r1578133 ] LUCENE-5376: carry over last branch Add a demo search server Key: LUCENE-5376 URL: https://issues.apache.org/jira/browse/LUCENE-5376 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: lucene-demo-server.tgz I think it'd be useful to have a demo search server for Lucene. Rather than being fully featured, like Solr, it would be minimal, just wrapping the existing Lucene modules to show how you can make use of these features in a server setting. The purpose is to demonstrate how one can build a minimal search server on top of APIs like SearchManager, SearcherLifetimeManager, etc. This is also useful for finding rough edges / issues in Lucene's APIs that make building a server unnecessarily hard. I don't think it should have back compatibility promises (except Lucene's index back compatibility), so it's free to improve as Lucene's APIs change. As a starting point, I'll post what I built for the eating your own dog food search app for Lucene's Solr's jira issues http://jirasearch.mikemccandless.com (blog: http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It uses Netty to expose basic indexing searching APIs via JSON, but it's very rough (lots nocommits). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5674) The rows improvement for QueryComponet
[ https://issues.apache.org/jira/browse/SOLR-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937246#comment-13937246 ] Shalin Shekhar Mangar commented on SOLR-5674: - I haven't gone through the patch yet but is SOLR-5463 useful for you? The rows improvement for QueryComponet -- Key: SOLR-5674 URL: https://issues.apache.org/jira/browse/SOLR-5674 Project: Solr Issue Type: Bug Components: contrib - Clustering Affects Versions: 4.3.1, 4.5.1, 4.6 Environment: JVM7 Reporter: Raintung Li Labels: QueryComponet, rows Attachments: SOLR-5674.txt For solr Rows issues: 1. Solr don't provide get full results API, usually customer will set the rows is Integer.maxvalue try to get the full results that cause the other issue. OOM issue in solr :SOLR-5661(https://issues.apache.org/jira/browse/SOLR-5661) How about open the API for rows=-1? That means return full results. Sometimes the result count will every biggest that will cause the heap OOM, but usually we can suggest the customer to make sure the result really small that can call this API. Actually we don't want to make the second call to get full results. For one is call API get total number, for two get the result set rows into total number. 2. A litter improve, because every shard node return results has been ordered. Add first shard list into the PriorityQueue that don't need compare again only filter the same unique id. 3. Create the PriorityQueue after check all shard return sizes, that can avoid the unnecessary memory cost especially biggest rows. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937245#comment-13937245 ] Ahmet Arslan commented on LUCENE-1486: -- One last thing that might come out of this jira is [~terje_eggestad] this [comment|https://issues.apache.org/jira/browse/LUCENE-1486?focusedCommentId=12900278page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12900278] and his fix. However I couldn't re-produce the problem he reported with new MockAnalyzer(random()); This problem could be analyzer specific. Wildcards, ORs etc inside Phrase queries Key: LUCENE-1486 URL: https://issues.apache.org/jira/browse/LUCENE-1486 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 2.4 Reporter: Mark Harwood Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch, TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch, junit_complex_phrase_qp_07_22_2009.patch An extension to the default QueryParser that overrides the parsing of PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries. The implementation feels a little hacky - this is arguably better handled in QueryParser itself. This works as a proof of concept for much of the query parser syntax. Examples from the Junit test include: checkMatches(\j* smyth~\, 1,2); //wildcards and fuzzies are OK in phrases checkMatches(\(jo* -john) smith\, 2); // boolean logic works checkMatches(\jo* smith\~2, 1,2,3); // position logic works. checkBadQuery(\jo* id:1 smith\); //mixing fields in a phrase is bad checkBadQuery(\jo* \smith\ \); //phrases inside phrases is bad checkBadQuery(\jo* [sma TO smZ]\ \); //range queries inside phrases not supported Code plus Junit test to follow... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3578) TestSort testParallelMultiSort reproducible seed failure
[
https://issues.apache.org/jira/browse/LUCENE-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937251#comment-13937251
]
ASF subversion and git services commented on LUCENE-3578:
-
Commit 1578134 from [~erickoerickson] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1578134 ]
Fix for LUCENE-3578, the ability to specify order for complex phrase queries
TestSort testParallelMultiSort reproducible seed failure
Key: LUCENE-3578
URL: https://issues.apache.org/jira/browse/LUCENE-3578
Project: Lucene - Core
Issue Type: Bug
Reporter: selckin
Assignee: Michael McCandless
Fix For: 4.0-ALPHA
trunk r1202157
{code}
[junit] Testsuite: org.apache.lucene.search.TestSort
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.978 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestSort
-Dtestmethod=testParallelMultiSort
-Dtests.seed=-2996f3e0f5d118c2:32c8e62dd9611f63:7a90f44586ae8263
-Dargs=-Dfile.encoding=UTF-8
[junit] WARNING: test method: 'testParallelMultiSort' left thread
running: Thread[pool-1-thread-1,5,main]
[junit] WARNING: test method: 'testParallelMultiSort' left thread
running: Thread[pool-1-thread-2,5,main]
[junit] WARNING: test method: 'testParallelMultiSort' left thread
running: Thread[pool-1-thread-3,5,main]
[junit] NOTE: test params are: codec=Lucene40:
{short=Lucene40(minBlockSize=98 maxBlockSize=214),
contents=PostingsFormat(name=MockSep), byte=PostingsFormat(name=SimpleText),
int=Pulsing40(freqCutoff=4 minBlockSize=58 maxBlockSize=186),
string=PostingsFormat(name=NestedPulsing), i18n=Lucene40(minBlockSize=98
maxBlockSize=214), long=PostingsFormat(name=Memory),
double=Pulsing40(freqCutoff=4 minBlockSize=58 maxBlockSize=186),
parser=MockVariableIntBlock(baseBlockSize=88), float=Lucene40(minBlockSize=98
maxBlockSize=214), custom=PostingsFormat(name=MockRandom)},
sim=RandomSimilarityProvider(queryNorm=false,coord=false):
{short=BM25(k1=1.2,b=0.75), tracer=DFR I(ne)B2, byte=DFR I(ne)B3(800.0),
contents=IB LL-LZ(0.3), int=DFR I(n)BZ(0.3), string=IB LL-D3(800.0), i18n=DFR
GB2, double=DFR I(ne)B2, long=DFR GB1, parser=DFR GL2,
float=BM25(k1=1.2,b=0.75), custom=DFR I(ne)Z(0.3)}, locale=ga_IE,
timezone=America/Louisville
[junit] NOTE: all tests run in this JVM:
[junit] [TestSort]
[junit] NOTE: Linux 3.0.6-gentoo amd64/Sun Microsystems Inc. 1.6.0_29
(64-bit)/cpus=8,threads=4,free=78022136,total=125632512
[junit] - ---
[junit] Testcase:
testParallelMultiSort(org.apache.lucene.search.TestSort): FAILED
[junit] expected:[ZJ]I but was:[JZ]I
[junit] junit.framework.AssertionFailedError: expected:[ZJ]I but
was:[JZ]I
[junit] at
org.apache.lucene.search.TestSort.assertMatches(TestSort.java:1245)
[junit] at
org.apache.lucene.search.TestSort.assertMatches(TestSort.java:1216)
[junit] at
org.apache.lucene.search.TestSort.runMultiSorts(TestSort.java:1202)
[junit] at
org.apache.lucene.search.TestSort.testParallelMultiSort(TestSort.java:855)
[junit] at
org.apache.lucene.util.LuceneTestCase$3$1.evaluate(LuceneTestCase.java:523)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:149)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:51)
[junit]
[junit]
[junit] Test org.apache.lucene.search.TestSort FAILED
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.
[ https://issues.apache.org/jira/browse/LUCENE-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937252#comment-13937252 ] Erick Erickson commented on LUCENE-3758: Fixed: trunk: r - 1578113 4x: r - 1578134 Allow the ComplexPhraseQueryParser to search order or un-order proximity queries. - Key: LUCENE-3758 URL: https://issues.apache.org/jira/browse/LUCENE-3758 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.0-ALPHA Reporter: Tomás Fernández Löbbe Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: LUCENE-3758.patch, LUCENE-3758.patch, LUCENE-3758.patch The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder value hardcoded to true. This could be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.
[ https://issues.apache.org/jira/browse/LUCENE-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-3758. Resolution: Fixed Fix Version/s: 5.0 Thanks Ahmet! Allow the ComplexPhraseQueryParser to search order or un-order proximity queries. - Key: LUCENE-3758 URL: https://issues.apache.org/jira/browse/LUCENE-3758 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.0-ALPHA Reporter: Tomás Fernández Löbbe Assignee: Erick Erickson Priority: Minor Fix For: 4.8, 5.0 Attachments: LUCENE-3758.patch, LUCENE-3758.patch, LUCENE-3758.patch The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder value hardcoded to true. This could be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
On 3/16/2014 5:35 AM, Michael McCandless wrote: On Sun, Mar 16, 2014 at 6:09 AM, Furkan KAMACI furkankam...@gmail.com wrote: I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 +1, Sonar looks really nice! I can be volunteer to integrate Sonar into Lucene/Solr project. Thank you Furkan. I haven't yet looked, but the *idea* of Sonar sounds quite awesome. +1 for me on a thank you, Furkan. The ides of march spam from Jira on version 4.7 had one benefit relating to this discussion: It put LUCENE-5130 on my radar. Would it be too much administrative @#!* to create an umbrella issue? I'd suggest LUCENE-5130 for this purpose, except that I'm not 100% positive that failing the build is the right answer. I fully understand the motivation ... it would certainly force us to face the issue! A bunch of smaller issues could be created to tackle subsections of the code, or perhaps to tackle a particular type of warning. This really doesn't change how invasive the patches would be, but if they come in smaller chunks, it might be easier to work around them. When it comes to warnings about things like missing serialVersionUID, should we generate a random number for each class, or use a default value? Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937255#comment-13937255 ] Erick Erickson commented on SOLR-5488: -- re: SOLR-5685 and all of the sudden FieldFacetTest started breaking. [~sbower] and [~houstonputman] I need a quick reply to this to make progress: I got past the first problem by changing the fieldFacets.txt, i.e. o.min.ff=int_id - o.min.ff=string_sd o.min.ff=long_ld - o.min.ff=date_dtd o.max.ff=int_id - o.max.ff=string_sd o.max.ff=long_ld - o.max.ff=date_dtd I just noticed that it looked odd, and when I changed it I got past the first problem, but this is making changes without real understanding. There are other places with the older pattern like this one that don't seem to break the test in BeforeClass so it makes me nervous: o.count.s.str=count(string_sd) o.count.s.date=count(date_dtd) o.count.ff=int_id o.count.ff=long_ld So I'm not sure whether the changes I made are just irrelevant or perhaps mask something completely different. ** Second problem: Everything else is failing, things like: Expected :[25.0, 26.0, 28.5, 27.0, 22.5, 23.5, 24.5, 25.5, 26.5, 27.5, 24.0] Actual :[25.0, 26.0, 27.0, 22.5, 23.5, 24.5, 25.5, 26.5, 27.5, 28.5, 24.0] Same numbers, just not in the same order. This one from: at org.apache.solr.analytics.facet.FieldFacetTest.medianFacetAscTest(FieldFacetTest.java:561) So is ordering important here or should the values be sorted before passing to assertEquals? As you an tell I have no real deep-level understanding of what this code is _supposed_ to do, which makes it difficult to have confidence if I sorted the expected and actual before passing to assertEquals or used ;). I can make the changes above if I have some clue that I'm not doing something foolish. That is, change all the patterns in the fieldFacets.txt and change the collections passed in to assertEquals to be sorted or some such. Thanks! Fix up test failures for Analytics Component Key: SOLR-5488 URL: https://issues.apache.org/jira/browse/SOLR-5488 Project: Solr Issue Type: Bug Affects Versions: 4.7, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, eoe.errors The analytics component has a few test failures, perhaps environment-dependent. This is just to collect the test fixes in one place for convenience when we merge back into 4.x -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5531) Allow ComplexPhraseQuery to accept fields
Erick Erickson created LUCENE-5531: -- Summary: Allow ComplexPhraseQuery to accept fields Key: LUCENE-5531 URL: https://issues.apache.org/jira/browse/LUCENE-5531 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.8, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Fix For: 4.8, 5.0 Breaking out a patch created by Tomas Fernandez Lobbe to from LUCENE-1486 so we can track this better. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5531) Allow ComplexPhraseQuery to accept fields
[ https://issues.apache.org/jira/browse/LUCENE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated LUCENE-5531: --- Attachment: LUCENE-5531.patch Tomas' patch from LUCENE-1486 so we can look at it separately and track it. Allow ComplexPhraseQuery to accept fields - Key: LUCENE-5531 URL: https://issues.apache.org/jira/browse/LUCENE-5531 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.8, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Fix For: 4.8, 5.0 Attachments: LUCENE-5531.patch Breaking out a patch created by Tomas Fernandez Lobbe to from LUCENE-1486 so we can track this better. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
[
https://issues.apache.org/jira/browse/LUCENE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ahmet Arslan updated LUCENE-5530:
-
Attachment: LUCENE-5530.patch
Remove role:de* type queries from text case. One term inside quotes is
somehow meaningless.
ComplexPhraseQueryParser throws ParseException for fielded queries
---
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Labels: complexPhrase
Fix For: 4.8
Attachments: LUCENE-5530.patch, LUCENE-5530.patch
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-5531) Allow ComplexPhraseQuery to accept fields
[ https://issues.apache.org/jira/browse/LUCENE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson closed LUCENE-5531. -- Resolution: Duplicate Ahmet and I created these at the same time Allow ComplexPhraseQuery to accept fields - Key: LUCENE-5531 URL: https://issues.apache.org/jira/browse/LUCENE-5531 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.8, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Fix For: 4.8, 5.0 Attachments: LUCENE-5531.patch Breaking out a patch created by Tomas Fernandez Lobbe to from LUCENE-1486 so we can track this better. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
[
https://issues.apache.org/jira/browse/LUCENE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937270#comment-13937270
]
Erick Erickson commented on LUCENE-5530:
Bah! Ahmet is wy ahead of me! Removed the patch I just uploaded to reduce
confusion.
ComplexPhraseQueryParser throws ParseException for fielded queries
---
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Labels: complexPhrase
Fix For: 4.8
Attachments: LUCENE-5530.patch, LUCENE-5530.patch
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
[
https://issues.apache.org/jira/browse/LUCENE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-5530:
---
Attachment: (was: LUCENE-5530.patch)
ComplexPhraseQueryParser throws ParseException for fielded queries
---
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Labels: complexPhrase
Fix For: 4.8
Attachments: LUCENE-5530.patch, LUCENE-5530.patch
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
[
https://issues.apache.org/jira/browse/LUCENE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-5530:
---
Attachment: LUCENE-5530.patch
Tomas' patch from LUCENE-1486 so we can start iterating.
ComplexPhraseQueryParser throws ParseException for fielded queries
---
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Labels: complexPhrase
Fix For: 4.8
Attachments: LUCENE-5530.patch, LUCENE-5530.patch
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ahmet Arslan updated SOLR-1604: --- Attachment: SOLR1604.patch QueryEqualityTest added. Wildcards, ORs etc inside Phrase Queries Key: SOLR-1604 URL: https://issues.apache.org/jira/browse/SOLR-1604 Project: Solr Issue Type: Improvement Components: query parsers, search Affects Versions: 1.4 Reporter: Ahmet Arslan Assignee: Erick Erickson Priority: Minor Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR1604.patch Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.
[ https://issues.apache.org/jira/browse/LUCENE-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937293#comment-13937293 ] Dmitry Kan commented on LUCENE-3758: [~erickerickson] right, agree, this should be handled in another jira as a local param. We have implemented this as an operator as we allow mixing ordered and unordered clauses in the same query. Allow the ComplexPhraseQueryParser to search order or un-order proximity queries. - Key: LUCENE-3758 URL: https://issues.apache.org/jira/browse/LUCENE-3758 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.0-ALPHA Reporter: Tomás Fernández Löbbe Assignee: Erick Erickson Priority: Minor Fix For: 4.8, 5.0 Attachments: LUCENE-3758.patch, LUCENE-3758.patch, LUCENE-3758.patch The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder value hardcoded to true. This could be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
[
https://issues.apache.org/jira/browse/LUCENE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned LUCENE-5530:
--
Assignee: Erick Erickson
ComplexPhraseQueryParser throws ParseException for fielded queries
---
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Assignee: Erick Erickson
Labels: complexPhrase
Fix For: 4.8
Attachments: LUCENE-5530.patch, LUCENE-5530.patch
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-828) A RequestProcessor to support updates
[ https://issues.apache.org/jira/browse/SOLR-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-828. Resolution: Won't Fix Fix Version/s: (was: 4.8) I think this is redundant now that we have atomic updates via stored fields and transaction logs. A RequestProcessor to support updates - Key: SOLR-828 URL: https://issues.apache.org/jira/browse/SOLR-828 Project: Solr Issue Type: New Feature Reporter: Noble Paul This is same as SOLR-139. A new issue is opened so that the UpdateProcessor approach is highlighted and we can easily focus on that solution. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1480) SpellCheck in the same index
[ https://issues.apache.org/jira/browse/SOLR-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1480. - Resolution: Won't Fix Fix Version/s: (was: 4.8) We have DirectSolrSpellChecker now via LUCENE-2507 SpellCheck in the same index Key: SOLR-1480 URL: https://issues.apache.org/jira/browse/SOLR-1480 Project: Solr Issue Type: New Feature Components: spellchecker Reporter: Shalin Shekhar Mangar There is really no reason why spell check has to be done through a separate index. In most cases the spell check index is built from a Solr field. With a few configured dynamic fields, an UpdateRequestProcessor and a SearchComponent, spell checking can be done from the main Solr index. This eliminates the spellcheck build phases and spellcheck can get to use the Java replication for free. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-1486) Wildcards, ORs etc inside Phrase queries
[ https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-1486. Resolution: Fixed The re-opens were from 2009. This stuff has been in Lucene for some time, and the comment Reopening so we don't forget to do this one makes me think this should have been closed a long time ago. NOTE: we're also doing more work with this in the 4.8 time frame, thus it's getting some attention now. Wildcards, ORs etc inside Phrase queries Key: LUCENE-1486 URL: https://issues.apache.org/jira/browse/LUCENE-1486 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 2.4 Reporter: Mark Harwood Assignee: Erick Erickson Priority: Minor Fix For: 4.8 Attachments: ComplexPhraseQueryParser.java, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, Lucene-1486 non default field.patch, TestComplexPhraseQuery.java, junit_complex_phrase_qp_07_21_2009.patch, junit_complex_phrase_qp_07_22_2009.patch An extension to the default QueryParser that overrides the parsing of PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries. The implementation feels a little hacky - this is arguably better handled in QueryParser itself. This works as a proof of concept for much of the query parser syntax. Examples from the Junit test include: checkMatches(\j* smyth~\, 1,2); //wildcards and fuzzies are OK in phrases checkMatches(\(jo* -john) smith\, 2); // boolean logic works checkMatches(\jo* smith\~2, 1,2,3); // position logic works. checkBadQuery(\jo* id:1 smith\); //mixing fields in a phrase is bad checkBadQuery(\jo* \smith\ \); //phrases inside phrases is bad checkBadQuery(\jo* [sma TO smZ]\ \); //range queries inside phrases not supported Code plus Junit test to follow... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937298#comment-13937298 ] Houston Putman commented on SOLR-5488: -- *** First Problem *** In the fieldFacets,txt did you change it like this? turning 'o.min.ff=string_sd' into 'o.min.ff=int_id' and 'o.min.ff=date_dtd' into 'o.min.ff=long_ld' If so that doesn't really make since. Because these are calculating the minimum integer value faceting over the string values, and the minimum long value faceting over the date values. If you made the changes above, then you would be calculating the mininum int value faceting over all of the int values, etc. So the change isn't a good test even if it passes. * *** Second Problem *** So the ordering is somewhat important. Solr, and the analytics component, automatically sort the results of field facet by the field being faceted on. I assumed this when writing the tests so if the results are coming back misordered, then either the test is either splitting up the values incorrectly or the analytics component is. Or the sorting gets mesed up somewhere in the test. I don't think the sorting is an issue in the component. Looking through the test code, a lot has been changed from what I wrote. The part that I don't recognize at all is the parsing of the response through methods like getDoubleList() etc. in AbstractAnalyticsFacetTest.java. Since the tests worked before those methods were changed, I would suggest looking at those parsing methods first. (Side note: the methods in FieldFacetTest.java that still have FacetAsc, like medianFacetAscTest and sumOfSquaresFacetAscTest, should be renamed without the FacetAsc part so that they are named like the rest of the methods. (The FacetAsc functionality was taken out a while ago.) So the methods mentioned above should be renamed to medianTest and sumOfSquaresTest, respectively, in addition to the similarly named methods. * I would highly discourage you from changing the patterns in the fieldFacets.txt. I had trouble keeping all of that stuff straight while writing it and I don't think that is where the issue is. I'm not able to run the tests right now, so that's all of the help I can give. Fix up test failures for Analytics Component Key: SOLR-5488 URL: https://issues.apache.org/jira/browse/SOLR-5488 Project: Solr Issue Type: Bug Affects Versions: 4.7, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, eoe.errors The analytics component has a few test failures, perhaps environment-dependent. This is just to collect the test fixes in one place for convenience when we merge back into 4.x -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5376) Add a demo search server
[ https://issues.apache.org/jira/browse/LUCENE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937302#comment-13937302 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1578144 from [~mikemccand] in branch 'dev/branches/lucene5376_2' [ https://svn.apache.org/r1578144 ] LUCENE-5376: merge trunk Add a demo search server Key: LUCENE-5376 URL: https://issues.apache.org/jira/browse/LUCENE-5376 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: lucene-demo-server.tgz I think it'd be useful to have a demo search server for Lucene. Rather than being fully featured, like Solr, it would be minimal, just wrapping the existing Lucene modules to show how you can make use of these features in a server setting. The purpose is to demonstrate how one can build a minimal search server on top of APIs like SearchManager, SearcherLifetimeManager, etc. This is also useful for finding rough edges / issues in Lucene's APIs that make building a server unnecessarily hard. I don't think it should have back compatibility promises (except Lucene's index back compatibility), so it's free to improve as Lucene's APIs change. As a starting point, I'll post what I built for the eating your own dog food search app for Lucene's Solr's jira issues http://jirasearch.mikemccandless.com (blog: http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It uses Netty to expose basic indexing searching APIs via JSON, but it's very rough (lots nocommits). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1130: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1130/ 1 tests failed. REGRESSION: org.apache.solr.cloud.OverseerTest.testOverseerFailure Error Message: Could not register as the leader because creating the ephemeral registration node in ZooKeeper failed Stack Trace: org.apache.solr.common.SolrException: Could not register as the leader because creating the ephemeral registration node in ZooKeeper failed at org.apache.zookeeper.KeeperException.create(KeeperException.java:119) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783) at org.apache.solr.common.cloud.SolrZkClient$10.execute(SolrZkClient.java:431) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73) at org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:428) at org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:385) at org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:372) at org.apache.solr.cloud.ShardLeaderElectionContextBase$1.execute(ElectionContext.java:127) at org.apache.solr.common.util.RetryUtil.retryOnThrowable(RetryUtil.java:31) at org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:122) at org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:164) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:108) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:156) at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:289) at org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:155) at org.apache.solr.cloud.OverseerTest.testOverseerFailure(OverseerTest.java:666) Build Log: [...truncated 53247 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:490: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:182: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/extra-targets.xml:77: Java returned: 1 Total time: 146 minutes 39 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
On 3/16/2014 12:26 PM, Shawn Heisey wrote: Would it be too much administrative @#!* to create an umbrella issue? I'd suggest LUCENE-5130 for this purpose, except that I'm not 100% positive that failing the build is the right answer. I fully understand the motivation ... it would certainly force us to face the issue! A bunch of smaller issues could be created to tackle subsections of the code, or perhaps to tackle a particular type of warning. This really doesn't change how invasive the patches would be, but if they come in smaller chunks, it might be easier to work around them. When it comes to warnings about things like missing serialVersionUID, should we generate a random number for each class, or use a default value? A further idea: We could limit this cleanup to trunk. I foresee three main effects, none of which seems like a bad thing to me: * We don't risk breaking the stable branch. * The cleanup might reveal actual bugs or clearly broken code. * Backporting gets harder, pushing us closer to the 5.0 release. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5530) ComplexPhraseQueryParser throws ParseException for fielded queries
[
https://issues.apache.org/jira/browse/LUCENE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937312#comment-13937312
]
ASF subversion and git services commented on LUCENE-5530:
-
Commit 1578148 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1578148 ]
LUCENE-5530 Allow the ComplexPhraseQueryParser to search order or un-order
proximity queries.
ComplexPhraseQueryParser throws ParseException for fielded queries
---
Key: LUCENE-5530
URL: https://issues.apache.org/jira/browse/LUCENE-5530
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7
Reporter: Ahmet Arslan
Assignee: Erick Erickson
Labels: complexPhrase
Fix For: 4.8
Attachments: LUCENE-5530.patch, LUCENE-5530.patch
Queries using QueryParser's non-default field e.g.
author:j* smith are not supported by ComplexPhraseQueryParser. For example
following code snippet
{code}
ComplexPhraseQueryParser qp = new
ComplexPhraseQueryParser(TEST_VERSION_CURRENT, defaultField, new
MockAnalyzer(new Random()));
qp.parse(author:\fred* smith\) ;
{code}
yields
{noformat}
Caused by: org.apache.lucene.queryparser.classic.ParseException: Cannot have
clause for field defaultField nested in phrase for field author
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.checkPhraseClauseIsForSameField(ComplexPhraseQueryParser.java:147)
at
org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.newTermQuery(ComplexPhraseQueryParser.java:135)
... 49 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
Just because some tool expresses distaste, doesn't imply that everyone here agrees that it's a problem we should fix. In my experience, the default Sonar rulesets contain many things that people here are prone to disagree with. Start with serialVersionUID: do we care? Why would we care? In what cases to we really believe that a sane person would be using Java serialization with a Lucene/Solr class? Sonar can also be a bit cranky; it arranges for various tools to run via mechanisms that sometimes conflict with the ways you might run them yourself. So I'd suggest a process like: 1. Someone proposes a set of (e.g.) checkstyle rules to live by. 2. That ruleset is refined by experiment. 3. We make violations fail the build. Then lather, rinse, repeat for other tools. Once we have rulesets we agree are worth enforcing, we can look to Sonar for a pretty way to visualize their results if we like. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
