[jira] Resolved: (SOLR-1315) new replication command needed to force a backup when there is no committed index data
[ https://issues.apache.org/jira/browse/SOLR-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1315. -- Resolution: Fixed committed r805675 thanks Jay > new replication command needed to force a backup when there is no committed > index data > -- > > Key: SOLR-1315 > URL: https://issues.apache.org/jira/browse/SOLR-1315 > Project: Solr > Issue Type: New Feature > Components: replication (java) >Affects Versions: 1.4 > Environment: Mac OS >Reporter: Jay >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1315.patch > > Original Estimate: 5h > Remaining Estimate: 5h > > Here is an email describing the problem, and a possible solution. > I agree. I think both options could be useful - perhaps a 'forceBackup' as > well? Documentation would take care of the rest. Have you added this info to > the wiki yet? > -- > - Mark > http://www.lucidimagination.com > On Thu, Jul 23, 2009 at 12:56 PM, solr jay wrote: > > Hi, > > > > I noticed that the backup request > > > > http://master_host:port/solr/replication?command=backup< > > http://master_host/solr/replication?command=backup> > - Hide quoted text - > > > > works only if there are committed index data, i.e. > > core.getDeletionPolicy().getLatestCommit() is not null. Otherwise, no > > backup > > is created. It sounds logical because if nothing has been committed since > > your last backup, it doesn't help much to do a new backup. However, > > consider > > this scenario: > > > > 1. a backup process is scheduled at 1:00AM every Monday > > 2. just before 1:00AM, the system is shutdown (for whatever reason), and > > then restarts > > 3. No index is committed before 1:00AM > > 4. at 1:00AM, backup process starts and no committed index is found, and > > therefore no backup (until next week) > > > > The probability of this scenario is probably small, but it still could > > happen, and it seems to me that if I want to backup index, a backup should > > be created whether there are new committed index or not. > > > > Your thoughts? > > > > Thanks, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated SOLR-1275: --- Attachment: SOLR-1275.patch * Added DirectUpdateHandlerTest.testExpungeDeletes which creates a bunch of docs (i.e. several segments), terms known to be in specific segments are found and deleted. Expunge deletes is called, the segments are fewer and the segments with the deleted terms no longer exist. * Added expungeDeletes functionality to DirectUpdateHandler2 * The patch randomly didn't create enough of the expected segments, this could be due to ConcurrentMergeScheduler. I couldn't reproduce consistently. > Add expungeDeletes to DirectUpdateHandler2 > -- > > Key: SOLR-1275 > URL: https://issues.apache.org/jira/browse/SOLR-1275 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1275.patch, SOLR-1275.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > expungeDeletes is a useful method somewhat like optimize is offered by > IndexWriter that can be implemented in DirectUpdateHandler2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a properties file
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744882#action_12744882 ] Noble Paul commented on SOLR-1335: -- bq.I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say.. Are we going to do thiat in 1.4 i.e solr.xml for single cores? But this properties file is a critical feature for our ops to deploy solr with replication feature. (The master server is only known at deploy time). currently we are shipping four different solrconfig.xml files I am not really worried about the specifics of how we implement this. My requirements are pretty simple * A core should be able to load properties from a properties file (any file name, any loaction is OK) * There should be one sensible default for that file name and location , just the way we have for schema and solrconfig What is your preference of doing this? > load core properties from a properties file > --- > > Key: SOLR-1335 > URL: https://issues.apache.org/jira/browse/SOLR-1335 > Project: Solr > Issue Type: New Feature >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch > > > There are few ways of loading properties in runtime, > # using env property using in the command line > # if you use a multicore drop it in the solr.xml > if not , the only way is to keep separate solrconfig.xml for each instance. > #1 is error prone if the user fails to start with the correct system > property. > In our case we have four different configurations for the same deployment . > And we have to disable replication of solrconfig.xml. > It would be nice if I can distribute four properties file so that our ops can > drop the right one and start Solr. Or it is possible for the operations to > edit a properties file but it is risky to edit solrconfig.xml if he does not > understand solr > I propose a properties file in the instancedir as solrcore.properties . If > present would be loaded and added as core specific properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1315) new replication command needed to force a backup when there is no committed index data
[ https://issues.apache.org/jira/browse/SOLR-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744870#action_12744870 ] Jay commented on SOLR-1315: --- tried it, and it looks good. > new replication command needed to force a backup when there is no committed > index data > -- > > Key: SOLR-1315 > URL: https://issues.apache.org/jira/browse/SOLR-1315 > Project: Solr > Issue Type: New Feature > Components: replication (java) >Affects Versions: 1.4 > Environment: Mac OS >Reporter: Jay >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1315.patch > > Original Estimate: 5h > Remaining Estimate: 5h > > Here is an email describing the problem, and a possible solution. > I agree. I think both options could be useful - perhaps a 'forceBackup' as > well? Documentation would take care of the rest. Have you added this info to > the wiki yet? > -- > - Mark > http://www.lucidimagination.com > On Thu, Jul 23, 2009 at 12:56 PM, solr jay wrote: > > Hi, > > > > I noticed that the backup request > > > > http://master_host:port/solr/replication?command=backup< > > http://master_host/solr/replication?command=backup> > - Hide quoted text - > > > > works only if there are committed index data, i.e. > > core.getDeletionPolicy().getLatestCommit() is not null. Otherwise, no > > backup > > is created. It sounds logical because if nothing has been committed since > > your last backup, it doesn't help much to do a new backup. However, > > consider > > this scenario: > > > > 1. a backup process is scheduled at 1:00AM every Monday > > 2. just before 1:00AM, the system is shutdown (for whatever reason), and > > then restarts > > 3. No index is committed before 1:00AM > > 4. at 1:00AM, backup process starts and no committed index is found, and > > therefore no backup (until next week) > > > > The probability of this scenario is probably small, but it still could > > happen, and it seems to me that if I want to backup index, a backup should > > be created whether there are new committed index or not. > > > > Your thoughts? > > > > Thanks, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-630) Spellchecker should not be case-sensitive and should be stopwords-aware
[ https://issues.apache.org/jira/browse/SOLR-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744860#action_12744860 ] Alex Baranov commented on SOLR-630: --- I would propose to close this bug. 1) of->oft Whether stop words are omitted or not depends on: a. If "q" parameter is used, then "queryAnalyzerFieldType" parameter is used to determine the analyzer for the query. If "queryAnalyzerFieldType" is not specified, then WhitespaceTokenizer is used. b. If "spellcheck.q" parameter is used, then query analyzer of the spellchecker field is used. 2) America->Americaa, america->[none] I couldn't reproduce that. The results are the same as for "America" as for "america". However, spellchecker is really case-sensitive. For example, if there is "AmErIcAa" in the spellchecker index then this suggestion won't appear neither for "America" nor for "america", but would appear for "AmErIcA". The reason, why America->Americaa, america->Americaa lies in the n-gram method which is used in lucene spellchecker: for America and america the same grams are defined, the only difference is "startN" gram. Actually there is still might be a difference in the results: the method works so that it boosts the relevance of the suggestion if the first N letters of it are the same as in the word under spellcheck. I'm not sure whether case-sensitiveness(is it a word?) is a bug or not. Anyway, finding suggestions as well as creating the index for spellchecker is delegated to the Lucene SpellChecker, so this is Lucene issue, not Solr. P.S. I believe that one can avoid case-sensitive issue by configuring properly the analyzers (e.g. for the spellchecker field). > Spellchecker should not be case-sensitive and should be stopwords-aware > --- > > Key: SOLR-630 > URL: https://issues.apache.org/jira/browse/SOLR-630 > Project: Solr > Issue Type: Bug > Components: spellchecker >Reporter: Otis Gospodnetic >Priority: Minor > Fix For: 1.5 > > > Here are 2 more bugs: > 1) > Search for: > united states of America > Suggests: > united states oft America > It looks like the SC doesn't check stopwords, and "of" is a stopword. Thus, > it does not exist in the index, > but "oft" does, so SC suggests "oft" and thinks "of" is misspelled. I think > the SC component should check the list of > stopwords, too, no? > 2) > Search for: > united states of America > Suggests: > united states oftAmericaa > The of->oft is described above. But note how SC suggested America->Americaa, > but it didn't do that for "america". > This looks like case-sensitivity problem. Shouldn't the SC be > case-insensitive? > I can't produce a patch now (no src handy), so I'm hoping Grant or somebody > else can do it based on this report. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1368) ms() function for date math
[ https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-1368: --- Attachment: SOLR-1368.patch Attaching new patch with tests. This now throws an exception if ms() is used on string-based date fields (as opposed to numeric/trie). > ms() function for date math > --- > > Key: SOLR-1368 > URL: https://issues.apache.org/jira/browse/SOLR-1368 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 1.4 > > Attachments: SOLR-1368.patch, SOLR-1368.patch > > > ms (milliseconds) function to use dates in function queries -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml
On Tue, Aug 18, 2009 at 2:30 PM, Chris Hostetter wrote: > We have other date fields we can use to show off date features. OK - any suggestions on what field to use for our example docs? It could either be a dynamic field or a normal one... but I'm drawing a creative blank for the name. -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744826#action_12744826 ] Yonik Seeley commented on SOLR-1367: bq. What's hard to understand about a callback mechanism? Callbacks are useful when you need to execute your own snippet of code in a different context - that's not the case here. bq. Also, why would two loops over the same list be the same performance as one? Because the iteration part is irrelevant compared to what else is done during the iteration. Iteration can be as simple as a pointer dereference. The callback approach has null pointer check whether to invoke the modifier or not... and that gets done even if no modifier will be used (but that will also be in the noise). bq. Now multiply the need to do this for every query and I think it would add up. It won't - it won't even be measurable. bq. The whole use case is very much a special case. Most people in most situations don't need to do this. Which would seem to argue against adding code to try and do it. That said, docListToSolrDocList isn't even used in Solr anywhere, so I don't care too much - it can be deprecated/removed later. Solr itself shouldn't use this method since it's not streamable. Allowing custom modifications while preserving streamability *does* call for callbacks... but not in 1.4 > Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList > > > Key: SOLR-1367 > URL: https://issues.apache.org/jira/browse/SOLR-1367 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1367.patch > > > Sometimes SearchComponents need to modify the DocList. Often times this > requires two loops over the (Solr)DocList: once to convert the DocList to > SolrDocList and then once to iterate the SolrDocList for the Search > Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744818#action_12744818 ] Grant Ingersoll commented on SOLR-1367: --- What's hard to understand about a callback mechanism? It's akin to FileFilter for File.listFiles or similar things. Also, why would two loops over the same list be the same performance as one? I suppose in the rows=10 or so case, it is in the noise, but, but if someone were getting deeper results than say 10, the Modifier approach would be faster. Now multiply the need to do this for every query and I think it would add up. The whole use case is very much a special case. Most people in most situations don't need to do this. But when you do need to do it, you do it all the time and you want it to be fast. That being said, people can implement it themselves. I just figured since the docListToSolrDocList method was already there, it would be a time saver. > Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList > > > Key: SOLR-1367 > URL: https://issues.apache.org/jira/browse/SOLR-1367 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1367.patch > > > Sometimes SearchComponents need to modify the DocList. Often times this > requires two loops over the (Solr)DocList: once to convert the DocList to > SolrDocList and then once to iterate the SolrDocList for the Search > Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: date functions and floats
: nice not to have to think about this on the client side. Perhaps I am just : missing something. In other words, do we support Lucene's DateTools : Resolution capabilities? currently the only way to do something like this with DateField is for the client to specify a rounding operation when indexing... 2009-12-14T01:01:01.004Z/DAY ...there was some discussion about adding options to the DateField that would allow rounding options to be specified in shcema.xml, but no one ever worked up a patch ... https://issues.apache.org/jira/browse/SOLR-741 -Hoss
[jira] Commented: (SOLR-1368) ms() function for date math
[ https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744814#action_12744814 ] Yonik Seeley commented on SOLR-1368: bq. if it's legal to call ms on a rounded date (ie: NOW/SECOND) then why shouldn't it be legal to use a trie field with coarse precision? It should (and I do have plans for that in the future). What I meant by that is the newer trie based fields are the only ones you can get milliseconds from (regardless of precision) as opposed to a date string. It's not practical to convert date strings to milliseconds/seconds on the fly from the fieldcache. Perhaps we should throw an exception rather than silently using ord for those string-date fields though? > ms() function for date math > --- > > Key: SOLR-1368 > URL: https://issues.apache.org/jira/browse/SOLR-1368 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 1.4 > > Attachments: SOLR-1368.patch > > > ms (milliseconds) function to use dates in function queries -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1368) ms() function for date math
[ https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744810#action_12744810 ] Hoss Man commented on SOLR-1368: bq. ms(field) a date field (needs to be a trie-date variant that has milliseconds available) why? if it's legal to call ms on a rounded date (ie: NOW/SECOND) then why shouldn't it be legal to use a trie field with coarse precision? > ms() function for date math > --- > > Key: SOLR-1368 > URL: https://issues.apache.org/jira/browse/SOLR-1368 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 1.4 > > Attachments: SOLR-1368.patch > > > ms (milliseconds) function to use dates in function queries -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744788#action_12744788 ] Yonik Seeley commented on SOLR-1367: It seems in this case that iteration is more straight-forward and easier to understand, and offers the same performance. > Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList > > > Key: SOLR-1367 > URL: https://issues.apache.org/jira/browse/SOLR-1367 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1367.patch > > > Sometimes SearchComponents need to modify the DocList. Often times this > requires two loops over the (Solr)DocList: once to convert the DocList to > SolrDocList and then once to iterate the SolrDocList for the Search > Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744784#action_12744784 ] Grant Ingersoll commented on SOLR-1367: --- B/c docListToSolrDocList also requires looping over the DocList. So, in the old case, you've iterated the DocList twice. In the new way, you only iterated it once. > Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList > > > Key: SOLR-1367 > URL: https://issues.apache.org/jira/browse/SOLR-1367 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1367.patch > > > Sometimes SearchComponents need to modify the DocList. Often times this > requires two loops over the (Solr)DocList: once to convert the DocList to > SolrDocList and then once to iterate the SolrDocList for the Search > Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Updating Lucene/Solr home pages with news of the Solr book
: Best way to make this happen is to submit patches to the desired projects : websites (and of course self add the book to the wiki spots too). By which Erik means patches to the website *sources* (not patches to the generated HTML). Both Solr and the main lucene site use forrest to generate the sites... Solr website... http://wiki.apache.org/solr/Website_Update_HOWTO http://svn.apache.org/repos/asf/lucene/solr/trunk/src/site/ Main Lucene website... http://svn.apache.org/repos/asf/lucene/site/ You might want to take a look at how LIA got added to the LUcene-Java left nav and submit a path that does hte same thing for Solr's site... http://svn.apache.org/viewvc?view=rev&revision=751729 -Hoss
[jira] Commented: (SOLR-1354) Pass HTTP request parameters through to XSL scripts
[ https://issues.apache.org/jira/browse/SOLR-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744774#action_12744774 ] Hoss Man commented on SOLR-1354: Lance: the topic of XSL params came up once upon a time, and before anyone ever got around to implementing it, someone pointed out that using echoParams you could get all of the params into the XML so that the template had access to them. you've already written the code to convert params to xsl:params ... using echoParams still seems like it's more generally useful, because it can work with any param, and allows for multi-valued params as well (giving the tempalte the power to use the first, or all). Is there any significant advantage you see to adding xsl:param support that echoParams *can't* handle? > Pass HTTP request parameters through to XSL scripts > --- > > Key: SOLR-1354 > URL: https://issues.apache.org/jira/browse/SOLR-1354 > Project: Solr > Issue Type: New Feature > Components: search > Environment: Any JDK from 1.5 onward. Any OS. Uses standard XSLTC > 'compiled'-only version of Apache Xalan distributed with the JRE. >Reporter: Lance Norskog >Priority: Minor > Attachments: rss2.patch > > > It is not possible to create a standard web application with the Solr > distribution without coding in XSL, Ruby, HTML/Javascript etc. > This patch is an experiment that allows you to configure an RSS 2.0 feed > through HTTP parameters. To do this, it supplies: > 1) a change to XSLTWriter.java to pass an HTTP parameter named 'tr.name' > through as an XSL parameter called 'name'. The XSL script must then declare > 'name' as a global parameter. > 2) example/solr/conf/xslt/rss2.xsl - a mostly complete implementation of RSS > 2.0. > 3) a sample in example/solr/conf/solrconfig.xml which > configures solr/rss2 as an RSS feed for the sample electronics store in > example/solr. This supplies all parameters for the RSS feed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (SOLR-1067) QueryParsing.parseFunction uses Singleton Core (SolrCore.getSolrCore())
: > : I think we've done everything reasonable for 1.4, moving the rest to 1.5 : > : > from a project management / CHANGES.txt clrity stanpoint, it seems like we : > should be creating new issues for any parts of issues like this one that : > we're pushing off post 1.4 ... otherwise 1.4's CHANGES.txt has a list of : > bugs that were fixed, but when you look up the bug details it says it's : > still open. and down the road 1.X will say it fixed hte exact same but. : : I guess this is something I'd avoid adding to CHANGES.txt all together : - it's really pretty internal stuff. That's a slippery slope dude ... even if something is in the internals it can have behavioral effects on people who don't touch it directly (not to mention plugin developers who might actually be touching it directly) I think just about everything should be in CHANGES.txt ... if someone upgrades and gets a weird bug, the first place (we want people) to look for explanations is CHANGES.txt ... in an ideal world it lets people post questions like "when i upgraded from 1.3 to 1.4 i started getting errors with XYZ, i noticed CHANGES.txt mentions ABC and it occured to me that i use XYZ w/ABC so maybe that's causing this bug?" leaving stuff out of CHANGES just because it's an internal change seems like it just makes everybodies life harder when bugs pop up. -Hoss
[jira] Updated: (SOLR-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
[ https://issues.apache.org/jira/browse/SOLR-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1371: --- Fix Version/s: 1.4 Assignee: Hoss Man any objections to me committing this before 1.4? (by this i mean the test changes, i can't imagine anyone would object to me fixing the bug in LukeRequestHandler) > LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field > - > > Key: SOLR-1371 > URL: https://issues.apache.org/jira/browse/SOLR-1371 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 1.3 >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 1.4 > > Attachments: SOLR-1371.patch > > > if a schema doesn't have a uniqueKey field specified, teh schema explorer > won't work, and logs this exception... > {code} > SEVERE: java.lang.NullPointerException > at > org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373) > at > org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > {code} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
[ https://issues.apache.org/jira/browse/SOLR-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1371: --- Attachment: SOLR-1371.patch patch that fixes the LukeRequestHandler, and adds a new "MinimalSchemaTest" to serve as a place to more tests like this in the future. In an attempt to proactively spot problems like this, it uses the catchall solrconfig.xml that many other test use and does some introspection to try and hit any request handler it can find with trivial input to make sure it doesn't barf. to make this work, i changed QueryElevationComponentTest to use a new solrconfig.xml (and in the process discovered a bug in the test where it wasn't hitting hte request handler it thought it was) any objects > LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field > - > > Key: SOLR-1371 > URL: https://issues.apache.org/jira/browse/SOLR-1371 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 1.3 >Reporter: Hoss Man > Attachments: SOLR-1371.patch > > > if a schema doesn't have a uniqueKey field specified, teh schema explorer > won't work, and logs this exception... > {code} > SEVERE: java.lang.NullPointerException > at > org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373) > at > org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > {code} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744748#action_12744748 ] Yonik Seeley commented on SOLR-1367: I'm puzzled wondering why this is an improvement. New: {code} SolrDocumentList sdocs = docListToSolrDocumentList(dlist,..., new SolrDocumentModifier() { void process(SolrDocument doc) { doc.add("foo",1); } }, ...); {code} Old: {code} SolrDocumentList sdocs = docListToSolrDocumentList(dlist,...,...); for (SolrDocument doc : sdocs) { d.add("foo",1); } {code} > Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList > > > Key: SOLR-1367 > URL: https://issues.apache.org/jira/browse/SOLR-1367 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1367.patch > > > Sometimes SearchComponents need to modify the DocList. Often times this > requires two loops over the (Solr)DocList: once to convert the DocList to > SolrDocList and then once to iterate the SolrDocList for the Search > Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744734#action_12744734 ] Matthew Woytowitz commented on SOLR-788: It's on the top of the patch. 772437 --- org/apache/solr/handler/MoreLikeThisHandler.java(revision 772437) +++ org/apache/solr/handler/MoreLikeThisHandler.java(working copy) Matt Woytowitz Software Enginneer ManTech International Corporation Phone: (703) 674-3674 Email: matthew.woytow...@mantech.com > MoreLikeThis should support distributed search > -- > > Key: SOLR-788 > URL: https://issues.apache.org/jira/browse/SOLR-788 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Priority: Minor > Attachments: MoreLikeThisComponentTest.patch, > SolrMoreLikeThisPatch.txt > > > The MoreLikeThis component should support distributed processing. > See SOLR-303. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
[ https://issues.apache.org/jira/browse/SOLR-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744710#action_12744710 ] Hoss Man commented on SOLR-1371: the fix seems pretty trivial, but i'd like to have a nice robust testcase of a "minimal" schema that we can have to help prevent little glitches like this in the future > LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field > - > > Key: SOLR-1371 > URL: https://issues.apache.org/jira/browse/SOLR-1371 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 1.3 >Reporter: Hoss Man > > if a schema doesn't have a uniqueKey field specified, teh schema explorer > won't work, and logs this exception... > {code} > SEVERE: java.lang.NullPointerException > at > org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373) > at > org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > {code} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field - Key: SOLR-1371 URL: https://issues.apache.org/jira/browse/SOLR-1371 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 1.3 Reporter: Hoss Man if a schema doesn't have a uniqueKey field specified, teh schema explorer won't work, and logs this exception... {code} SEVERE: java.lang.NullPointerException at org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373) at org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) {code} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Updating Lucene/Solr home pages with news of the Solr book
David, Best way to make this happen is to submit patches to the desired projects websites (and of course self add the book to the wiki spots too). And congrats on the book! I know it's a lot of work, more than one expects going into it. And the never ending Solr 1.4 release hasn't helped either. Erik On Aug 18, 2009, at 4:30 PM, David Smiley @MITRE.org wrote: Hello Solr devs. I'd like to see news of my book "Solr 1.4 Enterprise Search Server" placed on the Solr home page. Yonik suggested that Lucene's home page would also be suitable. The more people that buy the book, the more that Apache Software Foundation is supported (5% royalties). The link to PACKT should be: http://www.packtpub.com/solr-1-4-enterprise-search-server?utm_source=http%3A%20%2F%2Flucene.apache.org%2Fsolr%2F&utm_medium=spons&utm_content=pod&utm_campa%20ign=mdb_000275 (yes it's kinda long; it's used to track the link click-through). You can also see an image on PACKT's site. You can click through to a larger one if desired. I'm not sure if it would be appropriate for me to write the news blurb since I'm not a Lucene/Solr committer but I can if you'd like me to. ~ David Smiley -- View this message in context: http://www.nabble.com/Updating-Lucene-Solr-home-pages-with-news-of-the-Solr-book-tp25032908p25032908.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Updating Lucene/Solr home pages with news of the Solr book
Hello Solr devs. I'd like to see news of my book "Solr 1.4 Enterprise Search Server" placed on the Solr home page. Yonik suggested that Lucene's home page would also be suitable. The more people that buy the book, the more that Apache Software Foundation is supported (5% royalties). The link to PACKT should be: http://www.packtpub.com/solr-1-4-enterprise-search-server?utm_source=http%3A%20%2F%2Flucene.apache.org%2Fsolr%2F&utm_medium=spons&utm_content=pod&utm_campa%20ign=mdb_000275 (yes it's kinda long; it's used to track the link click-through). You can also see an image on PACKT's site. You can click through to a larger one if desired. I'm not sure if it would be appropriate for me to write the news blurb since I'm not a Lucene/Solr committer but I can if you'd like me to. ~ David Smiley -- View this message in context: http://www.nabble.com/Updating-Lucene-Solr-home-pages-with-news-of-the-Solr-book-tp25032908p25032908.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval
[ https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744686#action_12744686 ] Mark Miller commented on SOLR-1296: --- I'm not against exposing something package private for tests - anyone that jumps the fence to use that should know what they are getting themselves into. > Enable opening IndexReader with termInfosIndexDivisor and setting > IndexWriter's termIndexInterval > - > > Key: SOLR-1296 > URL: https://issues.apache.org/jira/browse/SOLR-1296 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, > SOLR-1296.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We need to enable opening an IndexReader with termInfosIndexDivisor set in > solrConfig. > We need to enable setting the termIndexInterval in SolrIndexConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-705) Distributed search should optionally return docID->shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-705: --- Fix Version/s: (was: 1.4) 1.5 Moving this issue to 1.5 so that the details could be worked out with less haste. http://www.lucidimagination.com/search/document/1f2e56f58162679d/response_writers_and_doclists > Distributed search should optionally return docID->shard map > > > Key: SOLR-705 > URL: https://issues.apache.org/jira/browse/SOLR-705 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 > Environment: all >Reporter: Brian Whitman >Assignee: Ryan McKinley > Fix For: 1.5 > > Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, > SOLR-705.patch, SOLR-705.patch, SOLR-705.patch > > > SOLR-303 queries with &shards parameters set need to return the dociD->shard > mapping in the response. Without it, updating/deleting documents when the # > of shards is variable is hard. We currently set this with a special > requestHandler that filters /update and inserts the shard as a field in the > index but it would be better if the shard location came back in the query > response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory
[ https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744682#action_12744682 ] Kevin Osborn commented on SOLR-1365: Thanks for the comments. I'll make the changes for Erik's suggestions and come up with some tests. If it gets into 1.4, great. If not, then it is not a huge deal since this is already production code for us. But, if it could be put into the main code base, then even better. > Add configurable Sweetspot Similarity factory > - > > Key: SOLR-1365 > URL: https://issues.apache.org/jira/browse/SOLR-1365 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Kevin Osborn >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1365.patch > > > This is some code that I wrote a while back. > Normally, if you use SweetSpotSimilarity, you are going to make it do > something useful by extending SweetSpotSimilarity. So, instead, I made a > factory class and an configurable SweetSpotSimilarty. There are two classes. > SweetSpotSimilarityFactory reads the parameters from schema.xml. It then > creates an instance of VariableSweetSpotSimilarity, which is my custom > SweetSpotSimilarity class. In addition to the standard functions, it also > handles dynamic fields. > So, in schema.xml, you could have something like this: > > true > 1.0 > 1.5 > 1.3 > 2.0 > 1 > 1 > 0.5 > 2 > 9 > 0.2 > 2 > 7 >name="lengthNormFactorsSteepness_supplierDescription_*">0.4 > > So, now everything is in a config file instead of having to create your own > subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval
[ https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744679#action_12744679 ] Jason Rutherglen commented on SOLR-1296: For a test I agree it's not worth exposing IW publicly however there should be a simple way to access it as a package protected variable? A great example of a public Lucene API being exposed from Solr that can easily break the system is getWrappedReader. IR is as canonical to Lucene as IW. And calling close on IR will also cause numerous errors for users. Why is it public, it's only used internally to Solr? The Solr policy as it's being described isn't making sense to me. An answer to the second question? {quote} bq. do we really need solrconfig-termindex.xml We probably don't want all the tests to have different behavior. {quote} > Enable opening IndexReader with termInfosIndexDivisor and setting > IndexWriter's termIndexInterval > - > > Key: SOLR-1296 > URL: https://issues.apache.org/jira/browse/SOLR-1296 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, > SOLR-1296.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We need to enable opening an IndexReader with termInfosIndexDivisor set in > solrConfig. > We need to enable setting the termIndexInterval in SolrIndexConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1143) Return partial results when a connection to a shard is refused
[ https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-1143: Attachment: SOLR-1143-3.patch You are right Grant. I guess I forgot about the request handler defaults when I was creating this patch... I have removed the possibility to configure partial results via the _return-partial-results_ property in the latest patch. The request handler defaults can perfectly configure partial results to be enabled by default. > Return partial results when a connection to a shard is refused > -- > > Key: SOLR-1143 > URL: https://issues.apache.org/jira/browse/SOLR-1143 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Nicolas Dessaigne > Fix For: 1.4 > > Attachments: SOLR-1143-2.patch, SOLR-1143-3.patch, SOLR-1143.patch > > > If any shard is down in a distributed search, a ConnectException it thrown. > Here's a little patch that change this behaviour: if we can't connect to a > shard (ConnectException), we get partial results from the active shards. As > for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we > set the parameter "partialResults" at true. > This patch also adresses a problem expressed in the mailing list about a year > ago > (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) > We have a use case that needs this behaviour and we would like to know your > thougths about such a behaviour? Should it be the default behaviour for > distributed search? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval
[ https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744650#action_12744650 ] Grant Ingersoll commented on SOLR-1296: --- bq. Can you describe the worst case scenario you imagine will happen if IndexWriter is exposed? Sure, someone who thinks they know what they are doing closes the IW when it shouldn't be closed causing exceptions, etc and emails to solr-user, etc. and wasting the communities time. However, the impetus is not on me to defend why it shouldn't be exposed, it's on you to show why it is proper to take something that is currently private and make it public just to pass a test. If it needs to be public for other use cases, fine, but generally speaking, I don't think variables, etc. should be made public just for testing purposes. That's bad OOD. > Enable opening IndexReader with termInfosIndexDivisor and setting > IndexWriter's termIndexInterval > - > > Key: SOLR-1296 > URL: https://issues.apache.org/jira/browse/SOLR-1296 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, > SOLR-1296.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We need to enable opening an IndexReader with termInfosIndexDivisor set in > solrConfig. > We need to enable setting the termIndexInterval in SolrIndexConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval
[ https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744648#action_12744648 ] Mark Miller commented on SOLR-1296: --- People may start to use it and count on it, and we will have to needlessly support that. A public class in Lucene will still occasionally break back compat, and come with maintenance/deprecation as well. Just because its public in Lucene, that doesn't mean it should be public in Solr. For each little thing, its arguably never that big a deal - but a good policy keeps a bunch of little things from creeping. -1 on exposing anything just for tests. > Enable opening IndexReader with termInfosIndexDivisor and setting > IndexWriter's termIndexInterval > - > > Key: SOLR-1296 > URL: https://issues.apache.org/jira/browse/SOLR-1296 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, > SOLR-1296.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We need to enable opening an IndexReader with termInfosIndexDivisor set in > solrConfig. > We need to enable setting the termIndexInterval in SolrIndexConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Can synonyms be defined in a multi-valued field or a database?
Kelly, We just had this problem. We implemented a custom SynonymFilterFactory that accessed a Spring context and from that a list of synonyms from the database via Hibernate. It was trivial to do and works quite well. Note that you have to extend BaseTokenFilterFactory; you cannot just extend SynonymFilterFactory. Lajos Kelly Taylor wrote: I need the ability to remotely administer synonyms for each of my Solr standalone instances. It seems that my only option is that of uploading a file per instance, restarting the respective Solr instance(s), and then rebuilding my indexes. Can synonyms be defined in a multi-valued field or a database in place of a file? Or can synonyms be administered in any way other than editing a file? -Kelly No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.59/2310 - Release Date: 08/17/09 18:04:00
[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval
[ https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744642#action_12744642 ] Jason Rutherglen commented on SOLR-1296: bq. Because it's not publicly exposed in Solr and exposing it just for the sake of testing doesn't seem wise. Can you describe the worst case scenario you imagine will happen if IndexWriter is exposed? > Enable opening IndexReader with termInfosIndexDivisor and setting > IndexWriter's termIndexInterval > - > > Key: SOLR-1296 > URL: https://issues.apache.org/jira/browse/SOLR-1296 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, > SOLR-1296.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We need to enable opening an IndexReader with termInfosIndexDivisor set in > solrConfig. > We need to enable setting the termIndexInterval in SolrIndexConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory
[ https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744643#action_12744643 ] Hoss Man commented on SOLR-1365: FWIW: if a new feature doesn't have any impact on existing users, and has good tests, then i say we might as well commit it for 1.4 (If we were talking about a new feature on an existing component, then i'd be hesitant because of how that feature might impact existing users of that component -- but in this case even if it has bad performance or some small bug that slips through tests, people have to go out of their way to use it) But grant's right: needs tests before it's really a subject for debate. > Add configurable Sweetspot Similarity factory > - > > Key: SOLR-1365 > URL: https://issues.apache.org/jira/browse/SOLR-1365 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Kevin Osborn >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1365.patch > > > This is some code that I wrote a while back. > Normally, if you use SweetSpotSimilarity, you are going to make it do > something useful by extending SweetSpotSimilarity. So, instead, I made a > factory class and an configurable SweetSpotSimilarty. There are two classes. > SweetSpotSimilarityFactory reads the parameters from schema.xml. It then > creates an instance of VariableSweetSpotSimilarity, which is my custom > SweetSpotSimilarity class. In addition to the standard functions, it also > handles dynamic fields. > So, in schema.xml, you could have something like this: > > true > 1.0 > 1.5 > 1.3 > 2.0 > 1 > 1 > 0.5 > 2 > 9 > 0.2 > 2 > 7 >name="lengthNormFactorsSteepness_supplierDescription_*">0.4 > > So, now everything is in a config file instead of having to create your own > subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1365) Add configurable Sweetspot Similarity factory
[ https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-1365: -- Fix Version/s: (was: 1.4) 1.5 Needs tests. Not sure this will make 1.4, as we are trying to not add new features at this point. > Add configurable Sweetspot Similarity factory > - > > Key: SOLR-1365 > URL: https://issues.apache.org/jira/browse/SOLR-1365 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Kevin Osborn >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1365.patch > > > This is some code that I wrote a while back. > Normally, if you use SweetSpotSimilarity, you are going to make it do > something useful by extending SweetSpotSimilarity. So, instead, I made a > factory class and an configurable SweetSpotSimilarty. There are two classes. > SweetSpotSimilarityFactory reads the parameters from schema.xml. It then > creates an instance of VariableSweetSpotSimilarity, which is my custom > SweetSpotSimilarity class. In addition to the standard functions, it also > handles dynamic fields. > So, in schema.xml, you could have something like this: > > true > 1.0 > 1.5 > 1.3 > 2.0 > 1 > 1 > 0.5 > 2 > 9 > 0.2 > 2 > 7 >name="lengthNormFactorsSteepness_supplierDescription_*">0.4 > > So, now everything is in a config file instead of having to create your own > subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Solr 1.4 Work
https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true Still 20ish issues to be worked on.
[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval
[ https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744638#action_12744638 ] Grant Ingersoll commented on SOLR-1296: --- bq. Why would we go through the effort? IW is a public Lucene class. Because it's not publicly exposed in Solr and exposing it just for the sake of testing doesn't seem wise. > Enable opening IndexReader with termInfosIndexDivisor and setting > IndexWriter's termIndexInterval > - > > Key: SOLR-1296 > URL: https://issues.apache.org/jira/browse/SOLR-1296 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, > SOLR-1296.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We need to enable opening an IndexReader with termInfosIndexDivisor set in > solrConfig. > We need to enable setting the termIndexInterval in SolrIndexConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1367. --- Resolution: Fixed Committed revision 805528. > Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList > > > Key: SOLR-1367 > URL: https://issues.apache.org/jira/browse/SOLR-1367 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1367.patch > > > Sometimes SearchComponents need to modify the DocList. Often times this > requires two loops over the (Solr)DocList: once to convert the DocList to > SolrDocList and then once to iterate the SolrDocList for the Search > Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml
: If you think "NOW" is a bad date value for the exampledocs, we could : change them to specific dates, but I'd rather avoid any defaults in : the example schema. but that's the whole point of the field ... that's why it's called "timestamp" ... it provides a timestamp of when a document was indexed. I'd rather just leave the timestampe field completley commented out with the comment about how it can be used if you uncomment. leaving a timestamp field in w/o a default value, and putting values into doc files is relaly confusing. We have other date fields we can use to show off date features. -Hoss
Can synonyms be defined in a multi-valued field or a database?
I need the ability to remotely administer synonyms for each of my Solr standalone instances. It seems that my only option is that of uploading a file per instance, restarting the respective Solr instance(s), and then rebuilding my indexes. Can synonyms be defined in a multi-valued field or a database in place of a file? Or can synonyms be administered in any way other than editing a file? -Kelly -- View this message in context: http://www.nabble.com/Can-synonyms-be-defined-in-a-multi-valued-field-or-a-database--tp25030768p25030768.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Commented: (SOLR-1335) load core properties from a properties file
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744629#action_12744629 ] Hoss Man commented on SOLR-1335: bq. For a single-core the filenames are always hardcoded like solrconfig.xml and schema.xml. solrconfig.xml filename can be overridden from web.xml, ...and they can be overridden in solr.xml -- that's my main points: you are adding a filewhose name is hardcoded and can't be changed under any circumstances. currently solr.xml is the _only_ field with those kinds of rules, because the solrconfig.xml and schema.xml filenames can be specified in solr.xml. I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say... bq. I wish the single core also becomes a multicore with one core and all these confusions can go away. ...i agree with you completley, but it's not going to happen overnight, and adding more hardcoded things like this is just a step backwards. Frankly: i don't even thing there should be a default name for this new properties file, i think that if you want Solr to load properties from a file for you, you should be required to use solr.xml, and specify a filename there -- that would also give us the benefit of letting people specify multiple filenames (which is my other big concern about a single magic filename: there can be only one of them. for something like schema.xml or solrconfig.xml that's not the end of the world because merging multiple files doesn't even make much sense, but property files are extremly simple, and it should be just as easy to specify 37 of them as it is to specify 1. bq. Do we really need to do it now because the properties file itself is optional and adding that to solr.xml can add to more clutter for a feature that is not widely used . Even if we add it later it is going to be backward compatible. If it's something we know we're going to want to do, and it's going to keep the code simpler in the long run, we might as well do it right the first time. there's already too much confusion between the distinction between the solr home dir, and the solr instance dir when dealing with solr.xml ... having a new magic filename just convolutes matters (looking at the code: i can't immediately tell, is the property file expected to be in the instanceDir, or the solr home? ... what if i have both? bq. do we really have a choice here? Solr needs solr.solr.home to be set as a system property and all testcases follow this pattern There shouldn't be any need for a test to set the solr.solr.home system property ... the TestHarness already takes care of initializing the core with the appropriate home dir. (if for some reason this features tickles a bit of core initialization that doesn't work properly with the TestHarness then we should fix the TestHarness ... it's probably out of date with some of the EmbeddedSolr best practices anyway) > load core properties from a properties file > --- > > Key: SOLR-1335 > URL: https://issues.apache.org/jira/browse/SOLR-1335 > Project: Solr > Issue Type: New Feature >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch > > > There are few ways of loading properties in runtime, > # using env property using in the command line > # if you use a multicore drop it in the solr.xml > if not , the only way is to keep separate solrconfig.xml for each instance. > #1 is error prone if the user fails to start with the correct system > property. > In our case we have four different configurations for the same deployment . > And we have to disable replication of solrconfig.xml. > It would be nice if I can distribute four properties file so that our ops can > drop the right one and start Solr. Or it is possible for the operations to > edit a properties file but it is risky to edit solrconfig.xml if he does not > understand solr > I propose a properties file in the instancedir as solrcore.properties . If > present would be loaded and added as core specific properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml
On Tue, Aug 18, 2009 at 2:03 PM, Chris Hostetter wrote: > : URL: http://svn.apache.org/viewvc?rev=804477&view=rev > : Log: > : add back timestamps to more example docs > > I'm confused ... why add NOW as a hardcoded value to all of these files? > ... why not put 'default="NOW"' back into the schema.xml? (that was the > whole point of the timestamp field in the example) It's part of having a fast example schema - it doesn't matter if the example documents are slow, but it does matter if the example schema is slow because it's doing stuff that others may not care about. Someone should be able to use the new example schema as-is, with their own dynamic fields or whatever, and get near-optimal performance. If you think "NOW" is a bad date value for the exampledocs, we could change them to specific dates, but I'd rather avoid any defaults in the example schema. -Yonik http://www.lucidimagination.com
Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml
: URL: http://svn.apache.org/viewvc?rev=804477&view=rev : Log: : add back timestamps to more example docs I'm confused ... why add NOW as a hardcoded value to all of these files? ... why not put 'default="NOW"' back into the schema.xml? (that was the whole point of the timestamp field in the example) -Hoss
[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval
[ https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744622#action_12744622 ] Jason Rutherglen commented on SOLR-1296: bq. This should do the trick... Why would we go through the effort? IW is a public Lucene class. bq. do we really need solrconfig-termindex.xml We probably don't want all the tests to have different behavior. > Enable opening IndexReader with termInfosIndexDivisor and setting > IndexWriter's termIndexInterval > - > > Key: SOLR-1296 > URL: https://issues.apache.org/jira/browse/SOLR-1296 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, > SOLR-1296.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > We need to enable opening an IndexReader with termInfosIndexDivisor set in > solrConfig. > We need to enable setting the termIndexInterval in SolrIndexConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CharFilter, analysis.jsp
Opened: https://issues.apache.org/jira/browse/SOLR-1370 I'll take a look into this tomorrow. Thanks, Koji Yonik Seeley wrote: On Mon, Aug 17, 2009 at 11:03 PM, Erik Hatcher wrote: That fixes it with analysis.jsp, but not with FieldAnalysisRequestHandler I don't think. Using that field definition below, and this request - http://localhost:8983/solr/analysis/field?analysis.fieldtype=html_text&analysis.fieldvalue=%3Chtml%3E%3Cbody%3Ewhatever%3C/body%3E%3C/html%3E I still see whatever come out of WhitespaceTokenizer. Does the consumer of an Analyzer from a FieldType have to do anything special to utilize CharFilter's? Or it should all "just work"? Normal users of the Analyzer should see it just work - but FieldAnalysisRequestHandler doesn't use the Analyzer... it pulls it apart and uses the parts separately. It would be up to that code to apply any char filters, and apparently it doesn't. -Yonik http://www.lucidimagination.com
[jira] Created: (SOLR-1370) call CharFilters in FieldAnalysisRequestHandler
call CharFilters in FieldAnalysisRequestHandler --- Key: SOLR-1370 URL: https://issues.apache.org/jira/browse/SOLR-1370 Project: Solr Issue Type: Bug Components: Analysis Affects Versions: 1.4 Reporter: Koji Sekiguchi Priority: Minor Currently, FieldAnalysisRequestHandler doesn't call CharFilters even if CharFilters are defined for the fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1368) ms() function for date math
[ https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-1368: --- Attachment: SOLR-1368.patch Attaching a draft of a patch that seems to work - still needs tests. > ms() function for date math > --- > > Key: SOLR-1368 > URL: https://issues.apache.org/jira/browse/SOLR-1368 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 1.4 > > Attachments: SOLR-1368.patch > > > ms (milliseconds) function to use dates in function queries -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1368) ms() function for date math
[ https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744578#action_12744578 ] Yonik Seeley commented on SOLR-1368: Floats sometimes don't have sufficient precision for subtracting dates: http://search.lucidimagination.com/search/document/be9fcf5bbc8fd574/date_functions_and_floats An ms() function both provides a way to introduce date constants, as well as subtract them. examples: ms(NOW) a constant ms(2009-12-14T01:01:01Z) a constant ms(field) a date field (needs to be a trie-date variant that has milliseconds available) ms(field1,field2) difference in milliseconds ms(NOW/SECOND,field1) difference in milliseconds > ms() function for date math > --- > > Key: SOLR-1368 > URL: https://issues.apache.org/jira/browse/SOLR-1368 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 1.4 > > > ms (milliseconds) function to use dates in function queries -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1369) Add HSQLDB Jar to example-dih
Add HSQLDB Jar to example-dih - Key: SOLR-1369 URL: https://issues.apache.org/jira/browse/SOLR-1369 Project: Solr Issue Type: Improvement Reporter: Eric Pugh I went back to show someone the Example-DIH and followed the wiki page directions. I then ran into an error because the hsqldb uses 1.8, and the hsqldb.jar I downloaded from hsqldb.org was 1.9. The 1.9 rc shows up above the 1.8 version. I see two approaches: 1) Be clearer on the docs, maybe embed a direct link to http://sourceforge.net/projects/hsqldb/files/hsqldb/hsqldb_1_8_0/hsqldb_1_8_0_10.zip/download. 2) include hsqldb.jar in the example. I am assuming the reason this wasn't done was because of licensing issues?? Also, any real reason to zip the hsqldb database? It's under 20k expanded and adds another step. Figured I'd get the wisdom of the crowds before changing. Eric -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1368) ms() function for date math
[ https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley reassigned SOLR-1368: -- Assignee: Yonik Seeley > ms() function for date math > --- > > Key: SOLR-1368 > URL: https://issues.apache.org/jira/browse/SOLR-1368 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 1.4 > > > ms (milliseconds) function to use dates in function queries -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1368) ms() function for date math
ms() function for date math --- Key: SOLR-1368 URL: https://issues.apache.org/jira/browse/SOLR-1368 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Fix For: 1.4 ms (milliseconds) function to use dates in function queries -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Response Writers and DocLists
On Tue, Aug 18, 2009 at 11:20 AM, Ryan McKinley wrote: > dooh, i mean pushing it out of 1.4 (or into 1.5) +1 - the feature will undoubtedly be very important in the future, but probably shouldn't be a blocker for 1.4 -Yonik
Re: Response Writers and DocLists
On Aug 18, 2009, at 10:01 AM, Grant Ingersoll wrote: On Aug 18, 2009, at 9:49 AM, Ryan McKinley wrote: Also, I'm thinking about having a real simple interface that would allow for, when materializing the Fields, to pass in something like a DocumentModifier, which would basically get the document right before it is to be returned (possibly inside the SolrIndexReader, but maybe this even belongs at the Lucene level similar to the FieldSelector, although it is likely too late for 2.9.) Through this DocModifier, one could easily add fields, etc. Too high level for Lucene I think, and nothing is currently needed for Lucene - a user calls doc() to get the document and then they can modify or add fields however they want. An interface could be useful for Solr... but getting 1.4 out the door is top priority. Agreed... i am wondering if pushing: https://issues.apache.org/jira/browse/SOLR-705 to 1.4 makes sense... It already is marked for 1.4 and has been for a while. dooh, i mean pushing it out of 1.4 (or into 1.5) ryan
[jira] Commented: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader
[ https://issues.apache.org/jira/browse/SOLR-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744542#action_12744542 ] Mark Miller commented on SOLR-1366: --- bq. This call is used only to retrieve the full path of the directory for informational purpose, so it shouldn't lead to a crash. The replication handler uses it a lot (assuming its a file) - I almost feel we should add some javadoc about how using non FSDirectory based IndexReaders is supported. I'm not even fully sure myself. Also, are we positive it behaves here correctly in SolrCore ? {code} File indexDirFile = new File(getIndexDir()).getCanonicalFile(); File newIndexDirFile = new File(newIndexDir).getCanonicalFile(); if (newestSearcher != null && solrConfig.reopenReaders && indexDirFile.equals(newIndexDirFile)) { {code} > UnsupportedOperationException may be thrown when using custom IndexReader > - > > Key: SOLR-1366 > URL: https://issues.apache.org/jira/browse/SOLR-1366 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: searcher.patch > > > If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and > IndexReader-s that it produces don't support IndexReader.directory() (such as > is the case with ParallelReader or MultiReader) then an uncaught > UnsupportedOperationException is thrown. > This call is used only to retrieve the full path of the directory for > informational purpose, so it shouldn't lead to a crash. Instead we could > supply other available information about the reader (e.g. from its toString() > method). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader
[ https://issues.apache.org/jira/browse/SOLR-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-1366: - Assignee: Mark Miller > UnsupportedOperationException may be thrown when using custom IndexReader > - > > Key: SOLR-1366 > URL: https://issues.apache.org/jira/browse/SOLR-1366 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: searcher.patch > > > If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and > IndexReader-s that it produces don't support IndexReader.directory() (such as > is the case with ParallelReader or MultiReader) then an uncaught > UnsupportedOperationException is thrown. > This call is used only to retrieve the full path of the directory for > informational purpose, so it shouldn't lead to a crash. Instead we could > supply other available information about the reader (e.g. from its toString() > method). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1143) Return partial results when a connection to a shard is refused
[ https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744518#action_12744518 ] Grant Ingersoll edited comment on SOLR-1143 at 8/18/09 7:19 AM: {quote} In this patch you return a partial result when a shard has failed by setting partialResults to true in the request or if you want it to for all requests your can add true to your search handler in your solrconfig.xml. If both are not specified, partial results are disabled. Currently the partialResults parameter overrides the return-partial-results property in the search handler. {quote} I'm not sure about the need for the return-partial-results static boolean. This could just be handled through the RequestHandler defaults, right? was (Author: gsingers): I'm not sure about the need for the return-partial-results static boolean. This could just be handled through the RequestHandler defaults, right? > Return partial results when a connection to a shard is refused > -- > > Key: SOLR-1143 > URL: https://issues.apache.org/jira/browse/SOLR-1143 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Nicolas Dessaigne > Fix For: 1.4 > > Attachments: SOLR-1143-2.patch, SOLR-1143.patch > > > If any shard is down in a distributed search, a ConnectException it thrown. > Here's a little patch that change this behaviour: if we can't connect to a > shard (ConnectException), we get partial results from the active shards. As > for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we > set the parameter "partialResults" at true. > This patch also adresses a problem expressed in the mailing list about a year > ago > (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) > We have a use case that needs this behaviour and we would like to know your > thougths about such a behaviour? Should it be the default behaviour for > distributed search? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1143) Return partial results when a connection to a shard is refused
[ https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744518#action_12744518 ] Grant Ingersoll commented on SOLR-1143: --- I'm not sure about the need for the return-partial-results static boolean. This could just be handled through the RequestHandler defaults, right? > Return partial results when a connection to a shard is refused > -- > > Key: SOLR-1143 > URL: https://issues.apache.org/jira/browse/SOLR-1143 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Nicolas Dessaigne > Fix For: 1.4 > > Attachments: SOLR-1143-2.patch, SOLR-1143.patch > > > If any shard is down in a distributed search, a ConnectException it thrown. > Here's a little patch that change this behaviour: if we can't connect to a > shard (ConnectException), we get partial results from the active shards. As > for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we > set the parameter "partialResults" at true. > This patch also adresses a problem expressed in the mailing list about a year > ago > (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) > We have a use case that needs this behaviour and we would like to know your > thougths about such a behaviour? Should it be the default behaviour for > distributed search? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Response Writers and DocLists
On Aug 18, 2009, at 9:49 AM, Ryan McKinley wrote: Also, I'm thinking about having a real simple interface that would allow for, when materializing the Fields, to pass in something like a DocumentModifier, which would basically get the document right before it is to be returned (possibly inside the SolrIndexReader, but maybe this even belongs at the Lucene level similar to the FieldSelector, although it is likely too late for 2.9.) Through this DocModifier, one could easily add fields, etc. Too high level for Lucene I think, and nothing is currently needed for Lucene - a user calls doc() to get the document and then they can modify or add fields however they want. An interface could be useful for Solr... but getting 1.4 out the door is top priority. Agreed... i am wondering if pushing: https://issues.apache.org/jira/browse/SOLR-705 to 1.4 makes sense... It already is marked for 1.4 and has been for a while.
Re: Response Writers and DocLists
Also, I'm thinking about having a real simple interface that would allow for, when materializing the Fields, to pass in something like a DocumentModifier, which would basically get the document right before it is to be returned (possibly inside the SolrIndexReader, but maybe this even belongs at the Lucene level similar to the FieldSelector, although it is likely too late for 2.9.) Through this DocModifier, one could easily add fields, etc. Too high level for Lucene I think, and nothing is currently needed for Lucene - a user calls doc() to get the document and then they can modify or add fields however they want. An interface could be useful for Solr... but getting 1.4 out the door is top priority. Agreed... i am wondering if pushing: https://issues.apache.org/jira/browse/SOLR-705 to 1.4 makes sense... since it should probably use the same interface/ strategy ryan
Re: Response Writers and DocLists
On Aug 18, 2009, at 8:25 AM, Grant Ingersoll wrote: On Aug 17, 2009, at 10:15 PM, Yonik Seeley wrote: Too high level for Lucene I think, and nothing is currently needed for Lucene - a user calls doc() to get the document and then they can modify or add fields however they want. An interface could be useful for Solr... but getting 1.4 out the door is top priority. Agreed, I think I may make a simple mod to the SolrPluginUtils for now to allow callback there. That would at least save one extra loop and it wouldn't require any lower-level changes. See SOLR-1367 for the SolrPluginUtils change.
[jira] Updated: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-1367: -- Attachment: SOLR-1367.patch Simple fix for this. Marked the interface as changeable pending some other fixes later. > Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList > > > Key: SOLR-1367 > URL: https://issues.apache.org/jira/browse/SOLR-1367 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1367.patch > > > Sometimes SearchComponents need to modify the DocList. Often times this > requires two loops over the (Solr)DocList: once to convert the DocList to > SolrDocList and then once to iterate the SolrDocList for the Search > Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList Key: SOLR-1367 URL: https://issues.apache.org/jira/browse/SOLR-1367 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.4 Sometimes SearchComponents need to modify the DocList. Often times this requires two loops over the (Solr)DocList: once to convert the DocList to SolrDocList and then once to iterate the SolrDocList for the Search Component. This can be seen in SOLR-773, for example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: good performance news
On Aug 18, 2009, at 1:58 AM, Noble Paul നോബിള് नोब्ळ् wrote: I our internal testing , the binary request writer gave very good perf for large no:of docs. Yeah, that only makes sense. I was just curious on the overhead of XML in typical cases. I think all the native clients should use binary format. Though we did not benchmark it On Tue, Aug 18, 2009 at 2:57 AM, Grant Ingersoll wrote: On Aug 16, 2009, at 3:46 PM, Yonik Seeley wrote: I just profiled a CSV upload, and aside from the CSV parsing, Solr adds pretty much no overhead! I was expecting some non-trivial overhead due to Solr's SolrInputDocument, update processing pipeline, and update handler... but profiling showed that it amounted to less than 1%. 85% of the time was spent in Lucene's IndexWriter 12% of the time was spent in the CSV parser2 I'm curious how much overhead there is in parsing Solr XML. I will try some tests on that later if I get a chance. We really should push clients to use the Binary request/response formats in most cases. -- - Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Response Writers and DocLists
On Aug 17, 2009, at 10:15 PM, Yonik Seeley wrote: Too high level for Lucene I think, and nothing is currently needed for Lucene - a user calls doc() to get the document and then they can modify or add fields however they want. An interface could be useful for Solr... but getting 1.4 out the door is top priority. Agreed, I think I may make a simple mod to the SolrPluginUtils for now to allow callback there. That would at least save one extra loop and it wouldn't require any lower-level changes.
[jira] Updated: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader
[ https://issues.apache.org/jira/browse/SOLR-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-1366: Attachment: searcher.patch Patch that catches the exception and supplies IndexReader.toString() instead. > UnsupportedOperationException may be thrown when using custom IndexReader > - > > Key: SOLR-1366 > URL: https://issues.apache.org/jira/browse/SOLR-1366 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 1.4 > > Attachments: searcher.patch > > > If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and > IndexReader-s that it produces don't support IndexReader.directory() (such as > is the case with ParallelReader or MultiReader) then an uncaught > UnsupportedOperationException is thrown. > This call is used only to retrieve the full path of the directory for > informational purpose, so it shouldn't lead to a crash. Instead we could > supply other available information about the reader (e.g. from its toString() > method). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader
UnsupportedOperationException may be thrown when using custom IndexReader - Key: SOLR-1366 URL: https://issues.apache.org/jira/browse/SOLR-1366 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Reporter: Andrzej Bialecki Fix For: 1.4 Attachments: searcher.patch If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and IndexReader-s that it produces don't support IndexReader.directory() (such as is the case with ParallelReader or MultiReader) then an uncaught UnsupportedOperationException is thrown. This call is used only to retrieve the full path of the directory for informational purpose, so it shouldn't lead to a crash. Instead we could supply other available information about the reader (e.g. from its toString() method). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory
[ https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744434#action_12744434 ] Erik Hatcher commented on SOLR-1365: Any class loaded by SolrResourceLoader (any custom plugin, basically) can implement SolrCoreAware. > Add configurable Sweetspot Similarity factory > - > > Key: SOLR-1365 > URL: https://issues.apache.org/jira/browse/SOLR-1365 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Kevin Osborn >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1365.patch > > > This is some code that I wrote a while back. > Normally, if you use SweetSpotSimilarity, you are going to make it do > something useful by extending SweetSpotSimilarity. So, instead, I made a > factory class and an configurable SweetSpotSimilarty. There are two classes. > SweetSpotSimilarityFactory reads the parameters from schema.xml. It then > creates an instance of VariableSweetSpotSimilarity, which is my custom > SweetSpotSimilarity class. In addition to the standard functions, it also > handles dynamic fields. > So, in schema.xml, you could have something like this: > > true > 1.0 > 1.5 > 1.3 > 2.0 > 1 > 1 > 0.5 > 2 > 9 > 0.2 > 2 > 7 >name="lengthNormFactorsSteepness_supplierDescription_*">0.4 > > So, now everything is in a config file instead of having to create your own > subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1330) the details command shows current replication status when no replication is going on
[ https://issues.apache.org/jira/browse/SOLR-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay K. Ukey updated SOLR-1330: - Attachment: SOLR-1330.patch Patch with details mentioned previously available through JMX. > the details command shows current replication status when no replication is > going on > > > Key: SOLR-1330 > URL: https://issues.apache.org/jira/browse/SOLR-1330 > Project: Solr > Issue Type: Bug > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1330.patch, SOLR-1330.patch, SOLR-1330.patch, > SOLR-1330.patch > > > The details of current replication should be shown only when a replication is > going on. It would also be useful if the history of past replications are > also captured -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.