[jira] Commented: (SOLR-281) Search Components (plugins)
[ https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511678 ] Pieter Berkel commented on SOLR-281: I really like this modular approach to handling search requests, it will greatly simplify the process of adding new functionality (e.g. collapsing, faceting, more-like-this) to existing handlers without the need for unnecessary code replication. My primary goal is to extend the more-like-this handler capabilities and make them available to other handlers (such as dismax), and I think the proposed solution is a good approach. Some issues that I can forsee though are: 1) Ordering: its fairly obvious that certain handlers need to be called before others (e.g. standard / dismax query parsing before faceting / highlighting) however there may be cases where the required sequence of events may be more subtle (e.g. faceting the results of a more-like-this query). There probably needs to be some mechanism to determine the order in which the components are prepared / processed. 2) Dependancy: a situation may arise where a component depends on operations performed by another component (e.g. more-like-this may take advantage of the dismax 'bq' parameter), perhaps there needs to be some method of specifying component dependency so that the SearchHandler can load and process required components automatically? I hope this make sense, I'm fairly new to Solr development so I'm afraid my contributions to this issue would be mostly limited to (hopefully helpful) ideas and suggestions however I'm happy to tinker with the patched code from above and help test this new component framework as it is developed. cheers, Pieter Search Components (plugins) --- Key: SOLR-281 URL: https://issues.apache.org/jira/browse/SOLR-281 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Attachments: SOLR-281-SearchComponents.patch A request handler with pluggable search components for things like: - standard - dismax - more-like-this - highlighting - field collapsing For more discussion, see: http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#a11050274 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: removing most @author tags
On 7/10/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...Should we remove all author tags for solr code, or only for those who voted +1?... I'd say all author tags, and just in case here's my belated +1 to the proposal that started this thread. -Bertrand
Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build checkJunitPresence: compile-common: [mkdir] Created dir: /tmp/apache-solr-nightly/build/common [javac] Compiling 25 source files to /tmp/apache-solr-nightly/build/common [javac] Note: /tmp/apache-solr-nightly/src/java/org/apache/solr/common/params/DisMaxParams.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/core [javac] Compiling 206 source files to /tmp/apache-solr-nightly/build/core [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile-solrj-core: [mkdir] Created dir: /tmp/apache-solr-nightly/build/client/solrj [javac] Compiling 21 source files to /tmp/apache-solr-nightly/build/client/solrj [javac] Note: /tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/impl/CommonsHttpSolrServer.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compile-solrj: [javac] Compiling 2 source files to /tmp/apache-solr-nightly/build/client/solrj [javac] Note: /tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/embedded/JettySolrRunner.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 55 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 24, Failures: 0, Errors: 0, Time elapsed: 33.194 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.554 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 16.589 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.162 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.71 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.434 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.043 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.047 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.048 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.049 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.09 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.171 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.047 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.104 sec [junit] Running org.apache.solr.analysis.TestTrimFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.161 sec [junit] Running org.apache.solr.analysis.TestWordDelimiterFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 11.795 sec [junit] Running org.apache.solr.common.SolrDocumentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.049 sec [junit] Running org.apache.solr.common.params.SolrParamTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.088 sec [junit] Running org.apache.solr.common.util.ContentStreamTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.391 sec [junit] Running org.apache.solr.common.util.IteratorChainTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.046 sec
Hudson build is back to normal: Solr-Nightly #139
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/139/changes
[jira] Updated: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-215: --- Attachment: solr-215.patch.zip updated for trunk 555252; should apply cleanly now (a few fuzzies but no rejects). Yonik, About backwards compatibility named cores, the 'null' core (ie the core named 'null') is equivalent to the (non-solr215-patched) original version; SolrCore.getSolrCore() returns that core. Besides the obvious SolrConfig.config that has been removed, I dont (fore)see any other non-compatible behaviors. Henri Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-215.patch, solr-215.patch, solr-215.patch, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch, solr-trunk-542847.patch, solr-trunk-src.patch WHAT: As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index. This patch is intended to allow multiple cores in Solr which also brings multiple indexes capability. WHY: The current Solr practical wisdom is that one schema - thus one index - is most likely to accomodate your indexing needs, using a filter to segregate documents if needed. If you really need multiple indexes, deploy multiple web applications. There are a some use cases however where having multiple indexes or multiple cores through Solr itself may make sense. Multiple cores: Deployment issues within some organizations where IT will resist deploying multiple web applications. Seamless schema update where you can create a new core and switch to it without starting/stopping servers. Embedding Solr in your own application (instead of 'raw' Lucene) and functionally need to segregate schemas collections. Multiple indexes: Multiple language collections where each document exists in different languages, analysis being language dependant. Having document types that have nothing (or very little) in common with respect to their schema, their lifetime/update frequencies or even collection sizes. HOW: The best analogy is to consider that instead of deploying multiple web-application, you can have one web-application that hosts more than one Solr core. The patch does not change any of the core logic (nor the core code); each core is configured behaves exactly as the one core in 1.2; the various caches are per-core so is the info-bean-registry. What the patch does is replace the SolrCore singleton by a collection of cores; all the code modifications are driven by the removal of the different singletons (the config, the schema the core). Each core is 'named' and a static map (keyed by name) allows to easily manage them. You declare one servlet filter mapping per core you want to expose in the web.xml; this allows easy to access each core through a different url. USAGE (example web deployment, patch installed): Step0 java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml monitor.ml Will index the 2 documents in solr.xml monitor.xml Step1: http://localhost:8983/solr/core0/admin/stats.jsp Will produce the statistics page from the admin servlet on core0 index; 2 documents Step2: http://localhost:8983/solr/core1/admin/stats.jsp Will produce the statistics page from the admin servlet on core1 index; no documents Step3: java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1; running queries from the admin interface, you can verify indexes have different content. USAGE (Java code): //create a configuration SolrConfig config = new SolrConfig(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); PATCH MODIFICATIONS DETAILS (per package): org.apache.solr.core: The heaviest modifications are in SolrCore SolrConfig. SolrCore is the most obvious modification; instead of a singleton, there is a static map of cores keyed by names and assorted methods. To retain some compatibility, the 'null' named core replaces the singleton for the relevant methods, for instance SolrCore.getCore(). One small constraint on the core name is they can't contain '/' or '\' avoiding potential url file path problems. SolrConfig ( SolrIndexConfig) are now used to persist all configuration options that need to be quickly
[jira] Commented: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511783 ] Otis Gospodnetic commented on SOLR-215: --- Henri, I'm starting to suspect I'm doing something wrong here: svn co -r 555252 https://svn.apache.org/repos/asf/lucene/solr/trunk cd trunk svn info Path: . URL: https://svn.apache.org/repos/asf/lucene/solr/trunk Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 555252 Node Kind: directory Schedule: normal Last Changed Author: ryan Last Changed Rev: 554915 Last Changed Date: 2007-07-10 13:57:36 +0200 (Tue, 10 Jul 2007) Properties Last Updated: 2007-07-11 17:48:55 +0200 (Wed, 11 Jul 2007) wget https://issues.apache.org/jira/secure/attachment/12360039/solr-215.patch patch -p0 solr-215 patch.out $ grep .rej$ patch.out 1 out of 2 hunks FAILED -- saving rejects to file src/test/org/apache/solr/update/AutoCommitTest.java.rej 1 out of 3 hunks FAILED -- saving rejects to file src/test/org/apache/solr/analysis/TestKeepWordFilter.java.rej 1 out of 2 hunks FAILED -- saving rejects to file src/test/org/apache/solr/handler/XmlUpdateRequestHandlerTest.java.rej 2 out of 13 hunks FAILED -- saving rejects to file src/java/org/apache/solr/schema/IndexSchema.java.rej 1 out of 1 hunk FAILED -- saving rejects to file src/java/org/apache/solr/analysis/PhoneticFilter.java.rej 1 out of 14 hunks FAILED -- saving rejects to file src/java/org/apache/solr/search/SolrIndexSearcher.java.rej 3 out of 17 hunks FAILED -- saving rejects to file src/java/org/apache/solr/core/SolrCore.java.rej 4 out of 7 hunks FAILED -- saving rejects to file src/java/org/apache/solr/core/RequestHandlers.java.rej 2 out of 2 hunks FAILED -- saving rejects to file src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java.rej 1 out of 1 hunk FAILED -- saving rejects to file src/java/org/apache/solr/util/TestHarness.java.rej Am I doing something wrong? Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-215.patch, solr-215.patch, solr-215.patch, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch, solr-trunk-542847.patch, solr-trunk-src.patch WHAT: As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index. This patch is intended to allow multiple cores in Solr which also brings multiple indexes capability. WHY: The current Solr practical wisdom is that one schema - thus one index - is most likely to accomodate your indexing needs, using a filter to segregate documents if needed. If you really need multiple indexes, deploy multiple web applications. There are a some use cases however where having multiple indexes or multiple cores through Solr itself may make sense. Multiple cores: Deployment issues within some organizations where IT will resist deploying multiple web applications. Seamless schema update where you can create a new core and switch to it without starting/stopping servers. Embedding Solr in your own application (instead of 'raw' Lucene) and functionally need to segregate schemas collections. Multiple indexes: Multiple language collections where each document exists in different languages, analysis being language dependant. Having document types that have nothing (or very little) in common with respect to their schema, their lifetime/update frequencies or even collection sizes. HOW: The best analogy is to consider that instead of deploying multiple web-application, you can have one web-application that hosts more than one Solr core. The patch does not change any of the core logic (nor the core code); each core is configured behaves exactly as the one core in 1.2; the various caches are per-core so is the info-bean-registry. What the patch does is replace the SolrCore singleton by a collection of cores; all the code modifications are driven by the removal of the different singletons (the config, the schema the core). Each core is 'named' and a static map (keyed by name) allows to easily manage them. You declare one servlet filter mapping per core you want to expose in the web.xml; this allows easy to access each core through a different url. USAGE (example web deployment, patch installed): Step0 java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml monitor.ml Will index the 2 documents in solr.xml monitor.xml Step1: http://localhost:8983/solr/core0/admin/stats.jsp Will produce the statistics page from the admin servlet on core0 index; 2 documents Step2: http://localhost:8983/solr/core1/admin/stats.jsp Will produce the
[jira] Commented: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511796 ] Henri Biestro commented on SOLR-215: Otis, You need to grab the 'zipped' version aka solr-215.patch.zip (since June 23). I was trying to be space bandwidth friendly... Sorry I did not make it more obvious in some previous comments. Henri Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-215.patch, solr-215.patch, solr-215.patch, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch, solr-trunk-542847.patch, solr-trunk-src.patch WHAT: As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index. This patch is intended to allow multiple cores in Solr which also brings multiple indexes capability. WHY: The current Solr practical wisdom is that one schema - thus one index - is most likely to accomodate your indexing needs, using a filter to segregate documents if needed. If you really need multiple indexes, deploy multiple web applications. There are a some use cases however where having multiple indexes or multiple cores through Solr itself may make sense. Multiple cores: Deployment issues within some organizations where IT will resist deploying multiple web applications. Seamless schema update where you can create a new core and switch to it without starting/stopping servers. Embedding Solr in your own application (instead of 'raw' Lucene) and functionally need to segregate schemas collections. Multiple indexes: Multiple language collections where each document exists in different languages, analysis being language dependant. Having document types that have nothing (or very little) in common with respect to their schema, their lifetime/update frequencies or even collection sizes. HOW: The best analogy is to consider that instead of deploying multiple web-application, you can have one web-application that hosts more than one Solr core. The patch does not change any of the core logic (nor the core code); each core is configured behaves exactly as the one core in 1.2; the various caches are per-core so is the info-bean-registry. What the patch does is replace the SolrCore singleton by a collection of cores; all the code modifications are driven by the removal of the different singletons (the config, the schema the core). Each core is 'named' and a static map (keyed by name) allows to easily manage them. You declare one servlet filter mapping per core you want to expose in the web.xml; this allows easy to access each core through a different url. USAGE (example web deployment, patch installed): Step0 java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml monitor.ml Will index the 2 documents in solr.xml monitor.xml Step1: http://localhost:8983/solr/core0/admin/stats.jsp Will produce the statistics page from the admin servlet on core0 index; 2 documents Step2: http://localhost:8983/solr/core1/admin/stats.jsp Will produce the statistics page from the admin servlet on core1 index; no documents Step3: java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1; running queries from the admin interface, you can verify indexes have different content. USAGE (Java code): //create a configuration SolrConfig config = new SolrConfig(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); PATCH MODIFICATIONS DETAILS (per package): org.apache.solr.core: The heaviest modifications are in SolrCore SolrConfig. SolrCore is the most obvious modification; instead of a singleton, there is a static map of cores keyed by names and assorted methods. To retain some compatibility, the 'null' named core replaces the singleton for the relevant methods, for instance SolrCore.getCore(). One small constraint on the core name is they can't contain '/' or '\' avoiding potential url file path problems. SolrConfig ( SolrIndexConfig) are now used to persist all configuration options that need to be quickly accessible to the various components. Most of these variables were static like those found in SolrIndexSearcher. Mimicking the intent of these static variables, SolrConfig SolrIndexConfig use public final
RE: [jira] Commented: (SOLR-215) Multiple Solr Cores
One question I had was about backward compatibility... is there a way to register a null or default core that reverts to the original paths? Are there any other backward compatible gotchas (not related to custom java code)? I'm very excited about this patch as it would remove my current scheme of running shell scripts to hot deploy new solr webapps on the fly. Along with registering a default core so that all existing code/tests continue to work I think it would be nice to have the core name specified as a CGI param instead of (or in addition to) a url path. Otherwise, large section of client code (such as solrj/solr#) will need to be changed. For example: http://localhost:8983/solr/select?q=foocore=core1 http://localhost:8983/solr/update?core=core1 - will
Re: [jira] Commented: (SOLR 2 1 5) Multiple Solr Cores
On 7/11/07, Will Johnson [EMAIL PROTECTED] wrote: I think it would be nice to have the core name specified as a CGI param instead of (or in addition to) a url path. Otherwise, large section of client code (such as solrj/solr#) will need to be changed. Only if you want to talk to multiple cores over a single connection, right? Hopefully existing client code will allow the specification of the URL, and one would use http://localhost:8983/solr/core1/ Still might be useful as a param *if* it can be done efficiently. I wonder about the case when the param comes in via POST though. -Yonik
RE: [jira] Commented: (SOLR 2 1 5) Multiple Solr Cores
Most of the time I, and I imagine others, don't know the set of core's ahead of time. It seems somewhat wasteful to create a ton of solr server connections when a single one can handle things just as easily. I guess I don't see why this param should be any different than any others like output formats etc. As for POST's, you can still have cgi arguments and access them via the same servlet request parameters while accessing the input stream. I'll leave the efficiency issues to people more familiar with the patch but if it has to be in the url then you force people using solrj and other similar apis to create a MapString, SolrServer and manage them that way. - will -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik Seeley Sent: Wednesday, July 11, 2007 1:20 PM To: solr-dev@lucene.apache.org Subject: Re: [jira] Commented: (SOLR 2 1 5) Multiple Solr Cores On 7/11/07, Will Johnson [EMAIL PROTECTED] wrote: I think it would be nice to have the core name specified as a CGI param instead of (or in addition to) a url path. Otherwise, large section of client code (such as solrj/solr#) will need to be changed. Only if you want to talk to multiple cores over a single connection, right? Hopefully existing client code will allow the specification of the URL, and one would use http://localhost:8983/solr/core1/ Still might be useful as a param *if* it can be done efficiently. I wonder about the case when the param comes in via POST though. -Yonik
[jira] Assigned: (SOLR-297) RequiredSolrParams.getField* don't fallback to non-field specific values
[ https://issues.apache.org/jira/browse/SOLR-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned SOLR-297: - Assignee: Hoss Man RequiredSolrParams.getField* don't fallback to non-field specific values Key: SOLR-297 URL: https://issues.apache.org/jira/browse/SOLR-297 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Hoss Man Attachments: non-override-required-field-params.diff as discussed here... http://www.nabble.com/semantics-of-RequiredSolrParams.getFieldParam%28%22field%22%2C%22param%22%29-tf4032370.html#a11455114 the getFieldParam family of methods in RequiredSolrParams should not throw an exception if a non-field specific param value exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-297) RequiredSolrParams.getField* don't fallback to non-field specific values
[ https://issues.apache.org/jira/browse/SOLR-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-297. --- Resolution: Fixed Fix Version/s: 1.3 Committed revision 555345. RequiredSolrParams.getField* don't fallback to non-field specific values Key: SOLR-297 URL: https://issues.apache.org/jira/browse/SOLR-297 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Hoss Man Fix For: 1.3 Attachments: non-override-required-field-params.diff as discussed here... http://www.nabble.com/semantics-of-RequiredSolrParams.getFieldParam%28%22field%22%2C%22param%22%29-tf4032370.html#a11455114 the getFieldParam family of methods in RequiredSolrParams should not throw an exception if a non-field specific param value exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR 2 1 5) Multiple Solr Cores
Yonik Seeley wrote:
On 7/11/07, Will Johnson [EMAIL PROTECTED] wrote:
I think it would be nice to have the core name
specified as a CGI param instead of (or in addition to) a url path.
Otherwise, large section of client code (such as solrj/solr#) will need
to be changed.
Only if you want to talk to multiple cores over a single connection,
right?
Hopefully existing client code will allow the specification of the URL,
and
one would use http://localhost:8983/solr/core1/
Still might be useful as a param *if* it can be done efficiently.
I wonder about the case when the param comes in via POST though.
-Yonik
Passing the core name as an Http request parameter to use an existing core
is easy.
In the patched SolrServlet, replacing the first few lines of doGet with the
code that follows should do the trick.
-
private SolrCore getParameterCore(HttpServletRequest request) {
SolrCore core = null;
String[] score = request.getParameterValues(core);
if (score == null)
return null;
// lets try till we find one valid core
for(int c = 0; c score.length core == null; ++c)
core = SolrCore.getSolrCore(score[c]);
return core;
}
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
SolrCore core = getParameterCore(request);
if (core == null) {
if (this.core == null) {
Object ocore = request.getAttribute(org.apache.solr.SolrCore);
if (ocore instanceof SolrCore)
core = (SolrCore) core;
else
sendErr(404, no core to serve request, request, response);
}
else
core = this.core;
}
...
---
Creating a core dynamically needs a bit more work since we then need to pass
the config schema to use; suggested ways were naming convention or/and
even potentially upload them.
Hope this helps.
- Henri
--
View this message in context:
http://www.nabble.com/Re%3A--jira--Commented%3A-%28SOLR-2-1-5%29-Multiple-Solr-Cores-tf4063316.html#a11545863
Sent from the Solr - Dev mailing list archive at Nabble.com.
