[jira] [Commented] (SOLR-4079) Long core names break web gui appearance and functionality
[ https://issues.apache.org/jira/browse/SOLR-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536872#comment-13536872 ] Magnus Bergmark commented on SOLR-4079: --- The default 150px is very small. Only a handful of characters can fit in that space, so an increase in size would be welcome. After all, the sidebar is the only part with a hardcoded with, the main contents to the right of it grows with the browser window. I have a sidebar of 150px and main content of more than 1200px visible. I realize that my 27 screen isn't common, but the fact remain that there is a very strong weighing to the main contents and it will always be a lot larger than the sidebar. The title attribute is a very nice touch, however! :-) Long core names break web gui appearance and functionality -- Key: SOLR-4079 URL: https://issues.apache.org/jira/browse/SOLR-4079 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Environment: Reproduced in Chrome (23.0.1271.64) Reporter: Janko Luin Priority: Trivial Attachments: proposed_patch.css, Screen Shot 2012-11-15 at 10.40.29.png, SOLR-4079.patch Our data is split up over multiple cores with automatic naming, typically of the form articles_20080101154402_20080412181644. With long names like that, the sidebar will massively overshoot its boundaries and intrude so far into the main pane that it interferes with UI inputs and controls. Fixing this issue is trivial even within the browser, by introducing a custom stylesheet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4079) Long core names break web gui appearance and functionality
[ https://issues.apache.org/jira/browse/SOLR-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536872#comment-13536872 ] Magnus Bergmark edited comment on SOLR-4079 at 12/20/12 9:02 AM: - The default 150px is very small. Only a handful of characters can fit in that space, so an increase in size would be welcome. After all, the sidebar is the only part with a hardcoded width and the main contents to the right of it grows with the browser window. I have a sidebar of 150px and main content of more than 1200px visible. I realize that my 27 screen isn't common, but the fact remain that there is a very strong weighing to the main contents and it will always be a lot larger than the sidebar. The title attribute is a very nice touch, however! :-) was (Author: mange): The default 150px is very small. Only a handful of characters can fit in that space, so an increase in size would be welcome. After all, the sidebar is the only part with a hardcoded with, the main contents to the right of it grows with the browser window. I have a sidebar of 150px and main content of more than 1200px visible. I realize that my 27 screen isn't common, but the fact remain that there is a very strong weighing to the main contents and it will always be a lot larger than the sidebar. The title attribute is a very nice touch, however! :-) Long core names break web gui appearance and functionality -- Key: SOLR-4079 URL: https://issues.apache.org/jira/browse/SOLR-4079 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Environment: Reproduced in Chrome (23.0.1271.64) Reporter: Janko Luin Priority: Trivial Attachments: proposed_patch.css, Screen Shot 2012-11-15 at 10.40.29.png, SOLR-4079.patch Our data is split up over multiple cores with automatic naming, typically of the form articles_20080101154402_20080412181644. With long names like that, the sidebar will massively overshoot its boundaries and intrude so far into the main pane that it interferes with UI inputs and controls. Fixing this issue is trivial even within the browser, by introducing a custom stylesheet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3575) solr.xml should default to persist=true
[ https://issues.apache.org/jira/browse/SOLR-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509569#comment-13509569 ] Magnus Bergmark commented on SOLR-3575: --- related: it would be nice if the coming/going of cores didn't necessitate changing solr.xml Perhaps every directory under the solr home could implicitly define a collection. Not a good idea. We unload cores to save memory on some machines, then load them on demand. This would make it much harder for us to accomplish. Also, what would happen if a core was unloaded? solr.xml should default to persist=true --- Key: SOLR-3575 URL: https://issues.apache.org/jira/browse/SOLR-3575 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0-BETA, 5.0 The default of false is kind of silly IMO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3477) SOLR does not start up when no cores are defined
[ https://issues.apache.org/jira/browse/SOLR-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401227#comment-13401227 ] Magnus Bergmark commented on SOLR-3477: --- This still needs to be fixed for 3.6. We don't want to start running trunk in production here. SOLR does not start up when no cores are defined Key: SOLR-3477 URL: https://issues.apache.org/jira/browse/SOLR-3477 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.6 Environment: All environments Reporter: Sebastian Schaffert Assignee: Tommaso Teofili Priority: Critical Fix For: 4.0 Attachments: SOLR-3477-3_6.patch, SOLR-3477.patch Since version 3.6.0, Solr does not start up when no cores are defined in solr.xml. The problematic code is in CoresContainer.java, lines 171-173. org.apache.solr.common.SolrException: No cores were created, please check the logs for errors at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:172) ~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38] at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:96) ~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38] ... In our case, this is however a valid situation, because we create the cores programatically by calling the webservices to register new cores. The server is initially started with no cores defined, and depending on the configuration of our application, cores are then created dynamically. For the time being, we have to stick with version 3.5, which did not have this problem (or feature). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3477) SOLR does not start up when no cores are defined
[ https://issues.apache.org/jira/browse/SOLR-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401231#comment-13401231 ] Magnus Bergmark commented on SOLR-3477: --- Bug was introduced by SVN commit 1211850 in relation to SOLR-1730. Seems like just reverting that commit would fix the problem. SOLR does not start up when no cores are defined Key: SOLR-3477 URL: https://issues.apache.org/jira/browse/SOLR-3477 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.6 Environment: All environments Reporter: Sebastian Schaffert Assignee: Tommaso Teofili Priority: Critical Fix For: 4.0 Attachments: SOLR-3477-3_6.patch, SOLR-3477.patch Since version 3.6.0, Solr does not start up when no cores are defined in solr.xml. The problematic code is in CoresContainer.java, lines 171-173. org.apache.solr.common.SolrException: No cores were created, please check the logs for errors at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:172) ~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38] at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:96) ~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38] ... In our case, this is however a valid situation, because we create the cores programatically by calling the webservices to register new cores. The server is initially started with no cores defined, and depending on the configuration of our application, cores are then created dynamically. For the time being, we have to stick with version 3.5, which did not have this problem (or feature). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2649) MM ignored in edismax queries with operators
[ https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Bergmark updated SOLR-2649: -- Description: Hypothetical scenario: 1. User searches for stocks oil gold with MM set to 50% 2. User adds -stockings to the query: stocks oil gold -stockings 3. User gets no hits since MM was ignored and all terms where AND-ed together The behavior seems to be intentional, although the reason why is never explained: // For correct lucene queries, turn off mm processing if there // were explicit operators (except for AND). boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; (lines 232-234 taken from tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) This makes edismax unsuitable as an replacement to dismax; mm is one of the primary features of dismax. was: Hypothetical scenario: 1. User searches for stocks oil gold with MM set to 50% 2. User adds -stockings to the query: stocks oil gold -stockings 3. User gets no hits since MM was ignored and all terms where AND-ed together The behavior seems to be intentional, although the reason why is never explained: 232 // For correct lucene queries, turn off mm processing if there 233 // were explicit operators (except for AND). 234 boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; (taken from tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) This makes edismax unsuitable as an replacement to dismax; mm is one of the primary features of dismax. MM ignored in edismax queries with operators Key: SOLR-2649 URL: https://issues.apache.org/jira/browse/SOLR-2649 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.3 Reporter: Magnus Bergmark Priority: Minor Hypothetical scenario: 1. User searches for stocks oil gold with MM set to 50% 2. User adds -stockings to the query: stocks oil gold -stockings 3. User gets no hits since MM was ignored and all terms where AND-ed together The behavior seems to be intentional, although the reason why is never explained: // For correct lucene queries, turn off mm processing if there // were explicit operators (except for AND). boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; (lines 232-234 taken from tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) This makes edismax unsuitable as an replacement to dismax; mm is one of the primary features of dismax. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2649) MM ignored in edismax queries with operators
MM ignored in edismax queries with operators Key: SOLR-2649 URL: https://issues.apache.org/jira/browse/SOLR-2649 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.3 Reporter: Magnus Bergmark Priority: Minor Hypothetical scenario: 1. User searches for stocks oil gold with MM set to 50% 2. User adds -stockings to the query: stocks oil gold -stockings 3. User gets no hits since MM was ignored and all terms where AND-ed together The behavior seems to be intentional, although the reason why is never explained: 232 // For correct lucene queries, turn off mm processing if there 233 // were explicit operators (except for AND). 234 boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; (taken from tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) This makes edismax unsuitable as an replacement to dismax; mm is one of the primary features of dismax. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
