[jira] Updated: (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 updated SOLR-297: -- Summary: RequiredSolrParams.getField* don't fallback to non-field specific values (was: RequestSolrParams.getField* don't fallback to non-field specific values) doh. > 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 > 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] Commented: (SOLR-297) RequestSolrParams.getField* don't fallback to non-field specific values
[ https://issues.apache.org/jira/browse/SOLR-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511611 ] Ryan McKinley commented on SOLR-297: looks good to me. perhaps change the issue title from "RequestSolrParams" to "RequiredSolrParams" > RequestSolrParams.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 > 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] Updated: (SOLR-297) RequestSolrParams.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 updated SOLR-297: -- Attachment: non-override-required-field-params.diff patch and tests. if no objections, i'll commit fairly soon (tonight... tomorrow...) > RequestSolrParams.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 > 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] Created: (SOLR-297) RequestSolrParams.getField* don't fallback to non-field specific values
RequestSolrParams.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 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: removing most @author tags
On 10-Jul-07, at 1:59 PM, Yonik Seeley wrote: OK, so it seems there's general agreement to remove author tags. Should we remove all author tags for solr code, or only for those who voted +1? I say do it all. Anyone care to whip up a script?
Re: removing most @author tags
: Should we remove all author tags for solr code, or only for those who voted +1? eh. i say we do it all .. if anyone really wanted to keep their author tags they would have said something. : Anyone care to whip up a script? find -name \*.java -and -not -wholename \*.svn\* | xargs perl -i -ne 'print unless /[EMAIL PROTECTED]/' should i go ahead and commit ... or do people disagree with the "remove all" ? ... it's fairly easy to change it it to only remove a single author line. -Hoss
Re: removing most @author tags
OK, so it seems there's general agreement to remove author tags. Should we remove all author tags for solr code, or only for those who voted +1? Anyone care to whip up a script? -Yonik
[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_12511551
]
Yonik Seeley commented on SOLR-215:
---
I don't know if we should make Henri keep his patch up to date with the trunk
(since it's likely to continue evolving right now) until he's received more
feedback about the approach and we are ready to commit it.
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)?
> 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-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.
>
[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_12511454 ] Otis Gospodnetic commented on SOLR-215: --- Henri: I've finally started looking at this. The latest version of the patch doesn't apply 100% cleanly (e.g. src/java/org/apache/solr/handler/StaxUpdateRequestHandler.java has been replaced by src/java/org/apache/solr/handler/XppUpdateRequestHandler.java) and thus 'ant compile' results in several compilation errors. You can probably see the same locally, but just in case it make it easier for you, here is how patching looks for me: [EMAIL PROTECTED] trunk]$ patch -p0 < solr-215.patch patching file src/test/org/apache/solr/update/AutoCommitTest.java Hunk #1 FAILED at 55. 1 out of 2 hunks FAILED -- saving rejects to file src/test/org/apache/solr/update/AutoCommitTest.java.rej patching file src/test/org/apache/solr/analysis/TestBufferedTokenStream.java patching file src/test/org/apache/solr/analysis/TestPatternReplaceFilter.java patching file src/test/org/apache/solr/analysis/TestPhoneticFilter.java patching file src/test/org/apache/solr/analysis/AnalysisTestCase.java patching file src/test/org/apache/solr/analysis/TestPatternTokenizerFactory.java patching file src/test/org/apache/solr/analysis/TestRemoveDuplicatesTokenFilter.java patching file src/test/org/apache/solr/analysis/TestKeepWordFilter.java Hunk #1 FAILED at 27. 1 out of 3 hunks FAILED -- saving rejects to file src/test/org/apache/solr/analysis/TestKeepWordFilter.java.rej patching file src/test/org/apache/solr/analysis/BaseTokenTestCase.java patching file src/test/org/apache/solr/servlet/SolrRequestParserTest.java patching file src/test/org/apache/solr/servlet/DirectSolrConnectionTest.java patching file src/test/org/apache/solr/core/TestConfig.java patching file src/test/org/apache/solr/core/SolrCoreTest.java patching file src/test/org/apache/solr/core/RequestHandlersTest.java patching file src/test/org/apache/solr/core/TestBadConfig.java patching file src/test/org/apache/solr/schema/BadIndexSchemaTest.java patching file src/test/org/apache/solr/schema/NotRequiredUniqueKeyTest.java patching file src/test/org/apache/solr/schema/RequiredFieldsTest.java patching file src/test/org/apache/solr/schema/IndexSchemaTest.java patching file src/test/org/apache/solr/BasicFunctionalityTest.java patching file src/test/org/apache/solr/handler/StandardRequestHandlerTest.java patching file src/test/org/apache/solr/handler/XmlUpdateRequestHandlerTest.java Hunk #2 FAILED at 13. 1 out of 2 hunks FAILED -- saving rejects to file src/test/org/apache/solr/handler/XmlUpdateRequestHandlerTest.java.rej patching file src/test/org/apache/solr/handler/MoreLikeThisHandlerTest.java patching file src/java/org/apache/solr/schema/IndexSchema.java Hunk #2 succeeded at 57 (offset 1 line). Hunk #4 succeeded at 294 (offset 1 line). Hunk #5 FAILED at 303. Hunk #6 succeeded at 314 with fuzz 2. Hunk #7 FAILED at 327. Hunk #8 succeeded at 458 (offset 3 lines). Hunk #10 succeeded at 593 (offset 3 lines). Hunk #12 succeeded at 617 (offset 3 lines). 2 out of 13 hunks FAILED -- saving rejects to file src/java/org/apache/solr/schema/IndexSchema.java.rej patching file src/java/org/apache/solr/update/UpdateHandler.java patching file src/java/org/apache/solr/update/DirectUpdateHandler2.java Hunk #1 succeeded at 607 (offset 11 lines). patching file src/java/org/apache/solr/update/SolrIndexConfig.java patching file src/java/org/apache/solr/analysis/PatternTokenizerFactory.java patching file src/java/org/apache/solr/analysis/TokenizerFactory.java patching file src/java/org/apache/solr/analysis/PatternReplaceFilterFactory.java patching file src/java/org/apache/solr/analysis/BaseTokenFilterFactory.java patching file src/java/org/apache/solr/analysis/TrimFilterFactory.java patching file src/java/org/apache/solr/analysis/KeepWordFilterFactory.java patching file src/java/org/apache/solr/analysis/TokenFilterFactory.java patching file src/java/org/apache/solr/analysis/EnglishPorterFilterFactory.java Hunk #2 succeeded at 33 with fuzz 1. patching file src/java/org/apache/solr/analysis/PhoneticFilterFactory.java patching file src/java/org/apache/solr/analysis/WordDelimiterFilterFactory.java patching file src/java/org/apache/solr/analysis/SynonymFilterFactory.java Hunk #2 succeeded at 31 with fuzz 1. patching file src/java/org/apache/solr/analysis/SnowballPorterFilterFactory.java patching file src/java/org/apache/solr/analysis/EdgeNGramTokenizerFactory.java patching file src/java/org/apache/solr/analysis/PhoneticFilter.java Hunk #1 FAILED at 28. 1 out of 1 hunk FAILED -- saving rejects to file src/java/org/apache/solr/analysis/PhoneticFilter.java.rej patching file src/java/org/apache/solr/analysis/LengthFilterFactory.java patching file src/java/org/apache/solr/analysis/StopFilterFactory.java Hunk #2 succeeded at 32 with fuzz 1. patching file src/java/org/apache/solr/analys
[jira] Updated: (SOLR-282) snapshooter does not work under solaris
[ https://issues.apache.org/jira/browse/SOLR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Au updated SOLR-282: - Attachment: solr-282-solaris-and-osx.patch Attached is an updated patch that works for both Solaris and OS X. > snapshooter does not work under solaris > > > Key: SOLR-282 > URL: https://issues.apache.org/jira/browse/SOLR-282 > Project: Solr > Issue Type: Bug > Components: replication >Affects Versions: 1.2 > Environment: solaris >Reporter: Xuesong Luo >Assignee: Bill Au > Attachments: solr-282-solaris-and-osx.patch, solr-282.patch > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg04761.html > solr is able to find snapshooter but didn't generate any snapshot files > after the index is updated. I checked the > log, everything looks fine, then I run snapshooter from command line. It > failed because Solaris doesn't support > -l option for cp command. I changed command "cp -lr dir1 dir2" to: > mkdir dir2 > ln dir1/* dir2 > It seems working. Otis suggested to create an issue so that Bill Au & Co. can > fix this problem. > Please note: several other commands under solr/bin also have this problem. > You can use grep "cp -lr" to find all of them > and make similar changes. > I'm also curious why there is no error log when solr failed running > snapshooter. Shouldn't solr log an error message? > Thanks > Xuesong -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-213) snapshooter link creation doesn't work on OS X
[ https://issues.apache.org/jira/browse/SOLR-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511406 ] Bill Au commented on SOLR-213: -- I have attached an updated patch to SOLR-282 that works for both Solaris and OS X. > snapshooter link creation doesn't work on OS X > -- > > Key: SOLR-213 > URL: https://issues.apache.org/jira/browse/SOLR-213 > Project: Solr > Issue Type: Bug > Components: replication > Environment: OS X 10.4.9 >Reporter: Grant Ingersoll >Assignee: Bill Au >Priority: Minor > > The snapshooter script fails on the cp -l command when trying to create the > hard links for a snapshot. Should be able to use ln instead. Also should > look into if there are other issues on OS X. > There may be some relation to https://issues.apache.org/jira/browse/SOLR-93 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-296) NPE on LukeRequestHandler with numTerms=1
[ https://issues.apache.org/jira/browse/SOLR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-296. Resolution: Fixed committed in rev554915. Thanks Koji! > NPE on LukeRequestHandler with numTerms=1 > - > > Key: SOLR-296 > URL: https://issues.apache.org/jira/browse/SOLR-296 > Project: Solr > Issue Type: Bug >Reporter: Koji Sekiguchi >Assignee: Ryan McKinley > Attachments: SOLR-296.patch > > > To reproduce, access http://localhost:8983/solr/admin/luke?numTerms=1 for > non-empty index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: URL Encoding/Decoding
Thanks... I am backing out my code! On Jul 10, 2007, at 12:45 AM, Chris Hostetter wrote: the URL encoding/decoding in Solr only happens when dealing with HTTP based requests. When writing unit test that deal with the SolrTestHarness (and LocalSOlrQueryRequest which is what the loadLocal() and req() methods do under the covers) you shouldn't be doing any URL escaping because no URLs are involved. : new code that showed they were being encoded But I think it may : have been because the unit test don't operate through a regular HTTP : layer? bingo. -Hoss --- Principal OpenSource Connections Site: http://www.opensourceconnections.com Blog: http://blog.opensourceconnections.com Cell: 1-434-466-1467
[jira] Assigned: (SOLR-296) NPE on LukeRequestHandler with numTerms=1
[ https://issues.apache.org/jira/browse/SOLR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley reassigned SOLR-296: -- Assignee: Ryan McKinley > NPE on LukeRequestHandler with numTerms=1 > - > > Key: SOLR-296 > URL: https://issues.apache.org/jira/browse/SOLR-296 > Project: Solr > Issue Type: Bug >Reporter: Koji Sekiguchi >Assignee: Ryan McKinley > Attachments: SOLR-296.patch > > > To reproduce, access http://localhost:8983/solr/admin/luke?numTerms=1 for > non-empty index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-296) NPE on LukeRequestHandler with numTerms=1
[ https://issues.apache.org/jira/browse/SOLR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-296: Attachment: SOLR-296.patch The patch fixes this problem. And I put finally block to close TermEnum. > NPE on LukeRequestHandler with numTerms=1 > - > > Key: SOLR-296 > URL: https://issues.apache.org/jira/browse/SOLR-296 > Project: Solr > Issue Type: Bug >Reporter: Koji Sekiguchi > Attachments: SOLR-296.patch > > > To reproduce, access http://localhost:8983/solr/admin/luke?numTerms=1 for > non-empty index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-296) NPE on LukeRequestHandler with numTerms=1
NPE on LukeRequestHandler with numTerms=1 - Key: SOLR-296 URL: https://issues.apache.org/jira/browse/SOLR-296 Project: Solr Issue Type: Bug Reporter: Koji Sekiguchi To reproduce, access http://localhost:8983/solr/admin/luke?numTerms=1 for non-empty index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Solr-Nightly #138
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/138/changes Changes: [ryan] SOLR-292 - fix MoreLikeThis facet counting [ryan] SOLR-292 -- CHANGES.txt [yonik] queryResultMaxDocsCached: SOLR-291 [ryan] Removing a low-level entry from CHANGES.txt -- [...truncated 882 lines...] A client/ruby/solr-ruby/test/unit/document_test.rb A client/ruby/solr-ruby/test/unit/standard_response_test.rb AUclient/ruby/solr-ruby/test/unit/delimited_file_source_test.rb A client/ruby/solr-ruby/test/unit/xpath_test_file.xml AUclient/ruby/solr-ruby/test/unit/array_mapper_test.rb A client/ruby/solr-ruby/test/unit/field_test.rb AUclient/ruby/solr-ruby/test/unit/solr_mock_base.rb A client/ruby/solr-ruby/test/unit/add_document_test.rb AUclient/ruby/solr-ruby/test/unit/request_test.rb A client/ruby/solr-ruby/test/unit/commit_test.rb AUclient/ruby/solr-ruby/test/unit/xpath_mapper_test.rb AUclient/ruby/solr-ruby/test/unit/suite.rb A client/ruby/solr-ruby/test/unit/ping_test.rb A client/ruby/solr-ruby/test/unit/dismax_request_test.rb A client/ruby/solr-ruby/test/unit/response_test.rb AUclient/ruby/solr-ruby/test/unit/indexer_test.rb AUclient/ruby/solr-ruby/test/unit/connection_test.rb A client/ruby/solr-ruby/test/unit/delete_test.rb AUclient/ruby/solr-ruby/test/unit/tab_delimited.txt A client/ruby/solr-ruby/test/unit/hpricot_test_file.xml AUclient/ruby/solr-ruby/test/unit/standard_request_test.rb A client/ruby/solr-ruby/test/unit/hpricot_mapper_test.rb AUclient/ruby/solr-ruby/test/unit/data_mapper_test.rb AUclient/ruby/solr-ruby/test/unit/util_test.rb A client/ruby/solr-ruby/test/functional A client/ruby/solr-ruby/test/functional/test_solr_server.rb A client/ruby/solr-ruby/test/functional/server_test.rb A client/ruby/solr-ruby/test/conf AUclient/ruby/solr-ruby/test/conf/schema.xml A client/ruby/solr-ruby/test/conf/protwords.txt A client/ruby/solr-ruby/test/conf/stopwords.txt AUclient/ruby/solr-ruby/test/conf/solrconfig.xml A client/ruby/solr-ruby/test/conf/scripts.conf A client/ruby/solr-ruby/test/conf/admin-extra.html A client/ruby/solr-ruby/test/conf/synonyms.txt A client/ruby/solr-ruby/LICENSE.txt A client/ruby/solr-ruby/Rakefile A client/ruby/solr-ruby/script AUclient/ruby/solr-ruby/script/setup.rb AUclient/ruby/solr-ruby/script/solrshell A client/ruby/solr-ruby/lib A client/ruby/solr-ruby/lib/solr AUclient/ruby/solr-ruby/lib/solr/util.rb A client/ruby/solr-ruby/lib/solr/document.rb A client/ruby/solr-ruby/lib/solr/exception.rb AUclient/ruby/solr-ruby/lib/solr/indexer.rb AUclient/ruby/solr-ruby/lib/solr/response.rb AUclient/ruby/solr-ruby/lib/solr/connection.rb A client/ruby/solr-ruby/lib/solr/importer AUclient/ruby/solr-ruby/lib/solr/importer/delimited_file_source.rb AUclient/ruby/solr-ruby/lib/solr/importer/solr_source.rb AUclient/ruby/solr-ruby/lib/solr/importer/array_mapper.rb AUclient/ruby/solr-ruby/lib/solr/importer/mapper.rb AUclient/ruby/solr-ruby/lib/solr/importer/xpath_mapper.rb A client/ruby/solr-ruby/lib/solr/importer/hpricot_mapper.rb A client/ruby/solr-ruby/lib/solr/xml.rb AUclient/ruby/solr-ruby/lib/solr/importer.rb A client/ruby/solr-ruby/lib/solr/field.rb AUclient/ruby/solr-ruby/lib/solr/solrtasks.rb A client/ruby/solr-ruby/lib/solr/request A client/ruby/solr-ruby/lib/solr/request/ping.rb A client/ruby/solr-ruby/lib/solr/request/select.rb AUclient/ruby/solr-ruby/lib/solr/request/optimize.rb AUclient/ruby/solr-ruby/lib/solr/request/standard.rb A client/ruby/solr-ruby/lib/solr/request/delete.rb AUclient/ruby/solr-ruby/lib/solr/request/index_info.rb A client/ruby/solr-ruby/lib/solr/request/update.rb A client/ruby/solr-ruby/lib/solr/request/dismax.rb A client/ruby/solr-ruby/lib/solr/request/add_document.rb A client/ruby/solr-ruby/lib/solr/request/commit.rb A client/ruby/solr-ruby/lib/solr/request/base.rb AUclient/ruby/solr-ruby/lib/solr/request.rb A client/ruby/solr-ruby/lib/solr/response A client/ruby/solr-ruby/lib/solr/response/ping.rb AUclient/ruby/solr-ruby/lib/solr/response/optimize.rb A client/ruby/solr-ruby/lib/solr/response/standard.rb A client/ruby/solr-ruby/lib/solr/response/xml.rb A client/ruby/solr-ruby/lib/solr/response/ruby.rb A client/ruby/solr-ruby/lib/solr/response/delete.rb AUclient/ruby/solr-ruby/lib/solr/response/index_info.rb A client/ruby/solr-ruby/lib/solr/response/dismax.rb A client/ruby/solr-rub
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: 32.512 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.359 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 6.764 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.573 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.215 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.526 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.065 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.05 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.047 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.046 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.067 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.061 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.048 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.068 sec [junit] Running org.apache.solr.analysis.TestTrimFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.059 sec [junit] Running org.apache.solr.analysis.TestWordDelimiterFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.485 sec [junit] Running org.apache.solr.common.SolrDocumentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.051 sec [junit] Running org.apache.solr.common.params.SolrParamTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.054 sec [junit] Running org.apache.solr.common.util.ContentStreamTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.233 sec [junit] Running org.apache.solr.common.util.IteratorChainTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.069 sec [jun
[jira] Commented: (SOLR-295) Implementing MoreLikeThis support in DismaxRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511346 ] Pieter Berkel commented on SOLR-295: Thanks Ryan, I missed that original thread mentioned in SOLR-281 but completely agree with the line of thinking and proposals, (actually I was thinking the same when I made the above patch). There is little point in duplicating code across request handlers (leading to code bloat as you suggested), refactoring common functionality in separate components is going to ensure consistency in the response format across all handlers. I'll take a look at the patch submitted on SOLR-281 and see what I can do in terms of implementing my MLT ideas, however until the 'search component' framework concept has really been 'solidified', I'm afraid it's going to be difficult to extend. regards, Pieter > Implementing MoreLikeThis support in DismaxRequestHandler > - > > Key: SOLR-295 > URL: https://issues.apache.org/jira/browse/SOLR-295 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Pieter Berkel >Priority: Minor > Attachments: MoreLikeThis-DismaxRequestHandler_SOLR-295.patch > > > There's nothing too clever about this initial patch to be upload shortly, I > have simply extracted the MLT code from the StandardRequestHandler and > inserted it into the DismaxRequestHandler. However, there are some broader > MLT issues that I'd also like to address in the near future: > 1) (trivial) No "This response format is experimental" warning when MLT is > used with StandardRequestHandler (or DismaxRequestHandler). Not really a big > deal but at least makes developers aware of the possibility of future changes. > 2) (trivial) "org.apache.solr.common.util.MoreLikeThisParams" should perhaps > be moved to the more appropriate package "org.apache.solr.common.params". > 3) (non-trivial) The ability to specify the list of fields that should be > returned when MLT is invoked from an external handler (i.e. > StandardRequestHandler). Currently the field list (FL) parameter is > inherited from the main query but I can envisage cases where it would be > desirable to specify more or less return fields in the MLT query than the > main query. One complication is that "mlt.fl" is already used to specify the > fields used for similarity. Perhaps "mlt.fl" is not the best name for this > parameter and should be renamed to avoid potential conflict / confusion? > 4) (fairly-trivial) On a similar note to 3, there is currently no way to > specify a "start" value for the rows returned when MLT is invoked from an > external handler (e.g. StandardRequestHandler), it is hard-coded to 0 (i.e. > the first "mlt.count" documents matched). While I can see the logic in > naming the parameter "mlt.count", it does seem a little inconsistent and > perhaps it would be better to rename (or at least alias) it to "mlt.rows" to > be consistent with the CommonQueryParameters. Note that "mlt.start" is > fundamentally different to the "mlt.match.offset" parameter as the later > deals with documents *matching* the initial MLT query while the former deals > with documents *returned* by the MLT query (hope that makes sense). > I have created a patch that implemented "mlt.start" (to specify the start > doc) and added "mlt.rows" that could be used interchangeably with "mlt.count" > (but I would prefer to remove "mlt.count" altogether), but since it involves > changing the method definition of MoreLikeThisHelper.getMoreLikeThese(), I > wanted to get some opinions before submitting it. > 5) (non-trivial) Interesting Terms - the ability to return interesting term > information using the "mlt.interestingTerms" parameter when MLT is invoked > from an external handler. This is perhaps the most useful feature I am > looking to implement, I can see great benefit in being able to provide a list > of interesting terms or "keywords" for each document returned in a standard > or dismax query. Currently this only available from the MLT request handler > so perhaps the best approach would be to re-factor the "interestingTerms" > code in MoreLikeThisHandler class and put it somewhere in MoreLikeThisHelper > so it is available to all handlers? Again, I would appreciate any comments > or suggestions. > I've also noted the MLT features suggested by Tristan [ > http://www.nabble.com/MoreLikeThis-with-DisMax-boost-query---functions-tf4047187.html > ] which could quite possibly be rolled together with the above points -- I'm > not sure whether is is better to have a single ticket tracking several > related issues or create invididual tickets for each issue, however will be > happy to comply with the Solr issue tracking policy on
