[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 solr...@gmail.com 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-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-tabpanelfocusedCommentId=12744943#action_12744943 ] Lance Norskog commented on SOLR-1354: - Ow! Heck. The multi-valued param feature is a good point. One problem that came up is localization - fetching the local dateformat and formatting dates in the RSS feed according to the caller's locale. This would require pulling the incoming HTTP headers and feeding them to the XSL as parameters. Are there other request handlers that could use parameters? For example, the Velocity handler? How can it localize Velocity applications without the HTTP local header? 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 requestHandler in example/solr/conf/solrconfig.xml which configures solr/rss2 as an RSS feed for the sample electronics store in example/solr. This requestHandler 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.
[jira] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744951#action_12744951 ] Noble Paul commented on SOLR-1275: -- The patch looks fine to me . I plan to commit this shortly 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-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-tabpanelfocusedCommentId=12744993#action_12744993 ] Andrzej Bialecki commented on SOLR-1366: - Indeed, that complicates the matter ... It looks like using a non-file based IndexReader breaks replication. This is not a regression from 1.3, but the functionality to specify custom IndexReaders will be available in 1.4, so it should be clearly stated in docs that it prevents replication from working properly, until we rectify this issue. 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] 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-tabpanelfocusedCommentId=12744994#action_12744994
]
Erik Hatcher commented on SOLR-1335:
Noble - why aren't system properties viable for this? The replication
examples show master=${master} constructs, allowing a system property to set
master versus slave.
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-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-tabpanelfocusedCommentId=12744996#action_12744996 ] Andrzej Bialecki commented on SOLR-1366: - .. I haven't looked into it yet, but perhaps this could be solved by extending the replication handler to support multiple dirs, and for those IndexReader that don't support directory() try asking for getSubReaders() and use their directory() ... 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] 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-tabpanelfocusedCommentId=12745007#action_12745007 ] Noble Paul commented on SOLR-1335: -- bq.Noble - why aren't system properties viable for this? * Setting system properties is error prone. If we have a few dozen properties setting -D for each property is hard. The startup scripts are maintained by operations whereas this properties file should be delivered by the developers. This is more about a separation of concern * System properties are global properties. we should not corrupt that namespace 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-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745013#action_12745013 ] Grant Ingersoll commented on SOLR-1367: --- bq. 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 Right, it is likely used by a very small subset of people who: write their own SearchComp and modify the doclist. LocalSolr is one such case. If you look at PJ's patch on SOLR-773, you will see it in use. I think Ryan put it in, so he may have use case for it too. It is _definitely_ not needed by Solr itself. The modifier thing is also likely a temp fix until pseudo-fields and pluggable doc stores are in place. 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-tabpanelfocusedCommentId=12745019#action_12745019 ] Erik Hatcher commented on SOLR-1367: My opinion on this... this code should not be included in Solr yet. It can easily be added as custom utility or just a couple of lines of code into custom components. Until the components that need such utilities are added to Solr and until we agree on a cleaner way to add metadata to a document, I vote we revert this and not include it in Solr 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-1335) load core properties from a properties file
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745022#action_12745022 ] Erik Hatcher commented on SOLR-1335: Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that. Startup scripts - these could delegate to a developer maintained subscript that set variables to be included in -D settings. Global properties - yes, but you can namespace them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff. I'm not yet convinced the additional .properties feature is warranted. 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-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745024#action_12745024 ] Grant Ingersoll commented on SOLR-1367: --- Just because something isn't used internally by Solr, doesn't mean it isn't useful to Solr users. Why have Solr users write the same thing over and over again? It is perfectly reasonable for Solr to provide end user APIs. 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-tabpanelfocusedCommentId=12745029#action_12745029 ] Erik Hatcher commented on SOLR-1367: Just because it is useful in one situation does not mean it should be something the Solr committers must maintain either. I'm not convinced that adding fields to a document (in this way) is the right way to add metadata to the response, personally. I'm only one opinion out there though, but I'm -0.5 on this being in Solr 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-1335) load core properties from a properties file
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745028#action_12745028 ] Noble Paul commented on SOLR-1335: -- bq.Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that. these properties files are separately shipped and the developer decides what are the properties. bq.Global properties - yes, but you can namespace them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff. is this clean? I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it. 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] Issue Comment Edited: (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-tabpanelfocusedCommentId=12745028#action_12745028 ] Noble Paul edited comment on SOLR-1335 at 8/19/09 5:19 AM: --- bq.Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that. these properties files are separately shipped and the developer decides what are the properties. bq.Global properties - yes, but you can namespace them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff. is this clean? The system properties are available across the JVM . Why do you want a system wide property for something that is only used in solrconfig/schema? There is a chance of it conflicting with other system properties too. I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it. was (Author: noble.paul): bq.Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that. these properties files are separately shipped and the developer decides what are the properties. bq.Global properties - yes, but you can namespace them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff. is this clean? I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it. 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] Resolved: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1275. -- Resolution: Fixed committed: r805774 thanks Jason 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-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745032#action_12745032 ] Noble Paul commented on SOLR-1367: -- IMHO the performance improvement is almost none with this enhancement. And it is cleaner the old way. 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-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-tabpanelfocusedCommentId=12745042#action_12745042
]
Shalin Shekhar Mangar commented on SOLR-1366:
-
Yeah, ReplicationHandler assumes a file based IndexReader. We can document this
clearly.
{quote}
.. I haven't looked into it yet, but perhaps this could be solved by extending
the replication handler to support multiple dirs, and for those IndexReader
that don't support directory() try asking for getSubReaders() and use their
directory() ...
{quote}
Yes but that becomes complicated very fast. You'd need to know the correct
directory to which a newly downloaded file has to be written on the slave.
You'd also need to re-open readers selectively and you'd need to change their
directories (for cases where an existing file is to be deleted/replaced).
We anyway need to take a look at replication again after 1.4 with a focus on
Lucene's NRT capabilities.
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] Updated: (SOLR-1370) call CharFilters in FieldAnalysisRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-1370: - Attachment: SOLR-1370.patch The fix and test code. 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 Attachments: SOLR-1370.patch 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] Commented: (SOLR-1370) call CharFilters in FieldAnalysisRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745073#action_12745073 ] Erik Hatcher commented on SOLR-1370: Thanks Koji! Works well for me. commit whenever you like. 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 Attachments: SOLR-1370.patch 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] Assigned: (SOLR-1370) call CharFilters in FieldAnalysisRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi reassigned SOLR-1370: Assignee: Koji Sekiguchi 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 Assignee: Koji Sekiguchi Priority: Minor Fix For: 1.4 Attachments: SOLR-1370.patch 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-1370) call CharFilters in FieldAnalysisRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-1370: - Fix Version/s: 1.4 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 Assignee: Koji Sekiguchi Priority: Minor Fix For: 1.4 Attachments: SOLR-1370.patch 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] Commented: (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745079#action_12745079 ] Mike Anderson commented on SOLR-788: Yep, I got that part figured out finally. Unfortunately I'm getting back 0 results when I pass the shards parameter, as opposed to when it is omited. http://localhost:8983/solr/select?q=graphmlt=truemlt.fl=titlemlt.mindf=1mlt.mintf=1fl=id,score,titleshards=localhost:8983/solr returns: lst name=moreLikeThis result name=018639b9dfd5003c20c3ceb29df9d582 numFound=0 start=0 maxScore=0.0/ result name=83de9bc1953e36e44df8e95661983183 numFound=0 start=0 maxScore=0.0/ /lst where as http://localhost:8983/solr/select?q=graphmlt=truemlt.fl=titlemlt.mindf=1mlt.mintf=1fl=id,score,title returns lst name=moreLikeThis result name=018639b9dfd5003c20c3ceb29df9d582 numFound=1198 start=0 maxScore=3.3357687/ ...result docs result name=83de9bc1953e36e44df8e95661983183 numFound=487 start=0 maxScore=4.129801/ ...result docs /lst I poked around in the code, but couldn't really make any progress.. Any help would be greatly appreciated. -mike 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] Created: (SOLR-1372) Allow FieldAnalysisRequestHandler to get field value from content stream
Allow FieldAnalysisRequestHandler to get field value from content stream Key: SOLR-1372 URL: https://issues.apache.org/jira/browse/SOLR-1372 Project: Solr Issue Type: Improvement Components: Analysis Affects Versions: 1.4 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 1.4 FieldAnalysisRequestHandler currently only allows text to be analyzed to come from the analysis.fieldvalue parameter. It can be handy to point Solr at a file or URL to get text also using the content stream capability. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1372) Allow FieldAnalysisRequestHandler to get field value from content stream
[ https://issues.apache.org/jira/browse/SOLR-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-1372. Resolution: Fixed improvement committed. Allow FieldAnalysisRequestHandler to get field value from content stream Key: SOLR-1372 URL: https://issues.apache.org/jira/browse/SOLR-1372 Project: Solr Issue Type: Improvement Components: Analysis Affects Versions: 1.4 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 1.4 FieldAnalysisRequestHandler currently only allows text to be analyzed to come from the analysis.fieldvalue parameter. It can be handy to point Solr at a file or URL to get text also using the content stream capability. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SOLR-1372) Allow FieldAnalysisRequestHandler to get field value from content stream
: FieldAnalysisRequestHandler currently only allows text to be analyzed to : come from the analysis.fieldvalue parameter. It can be handy to point : Solr at a file or URL to get text also using the content stream : capability. Should we remove the analysis.fieldvalue param completely and have people use stream.body ? -Hoss
[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-tabpanelfocusedCommentId=12745092#action_12745092 ] Matthew Woytowitz commented on SOLR-788: It's been 3 months since I looked at this. Sounds fimiliar. Here are the params I pass with every MLT Query. private int minTermFrequency = MoreLikeThis.DEFAULT_MIN_TERM_FREQ; private int minWordLength = MoreLikeThis.DEFAULT_MIN_WORD_LENGTH; private int maxWordLength = MoreLikeThis.DEFAULT_MAX_WORD_LENGTH; private int maxQueryTerms = MoreLikeThis.DEFAULT_MAX_QUERY_TERMS; private int minDocFreq = MoreLikeThis.DEFAULT_MIN_DOC_FREQ; private int maxTokensToParse = MoreLikeThis.DEFAULT_MAX_NUM_TOKENS_PARSED; params.add(MoreLikeThisParams.MLT, Boolean.TRUE.toString()); params.add(MoreLikeThisParams.SIMILARITY_FIELDS, similarFields.split(,)); params.add(MoreLikeThisParams.MIN_TERM_FREQ, minTermFrequency + ); params.add(MoreLikeThisParams.MIN_WORD_LEN, minWordLength + ); params.add(MoreLikeThisParams.MAX_WORD_LEN, maxWordLength + ); params.add(MoreLikeThisParams.MAX_QUERY_TERMS, maxQueryTerms + ); params.add(MoreLikeThisParams.MAX_NUM_TOKENS_PARSED, maxTokensToParse + ); params.add(MoreLikeThisParams.MIN_DOC_FREQ, minDocFreq + ); Are you using a stock solr config? Can you send me the solr config and schema.xml? Are you logging the incoming queries to solr? You should see three requests. Your request, the shard request to get scores and ids and finally a request to return the fields you requested for the best matches. What does the second query look like? Take a look at that in your browser. If you run that query what do your results look like? 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-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
[ https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745091#action_12745091 ] Grant Ingersoll commented on SOLR-1367: --- OK, I will revert. 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] Issue Comment Edited: (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745079#action_12745079 ] Mike Anderson edited comment on SOLR-788 at 8/19/09 9:00 AM: - Yep, I got that part figured out finally. Unfortunately I'm getting back 0 results when I pass the shards parameter, as opposed to when it is omited. http://localhost:8983/solr/select?q=graphmlt=truemlt.fl=titlemlt.mindf=1mlt.mintf=1fl=id,score,titleshards=localhost:8983/solr returns: lst name=moreLikeThis result name=018639b9dfd5003c20c3ceb29df9d582 numFound=0 start=0 maxScore=0.0/ result name=83de9bc1953e36e44df8e95661983183 numFound=0 start=0 maxScore=0.0/ /lst where as http://localhost:8983/solr/select?q=graphmlt=truemlt.fl=titlemlt.mindf=1mlt.mintf=1fl=id,score,title returns lst name=moreLikeThis result name=018639b9dfd5003c20c3ceb29df9d582 numFound=1198 start=0 maxScore=3.3357687/ ...result docs result name=83de9bc1953e36e44df8e95661983183 numFound=487 start=0 maxScore=4.129801/ ...result docs /lst However, perhaps more pressing is that when the shards param is set my spellCheck component stops responding (I had to apply the distributed spellcheck patch as well). yikes... I poked around in the code, but couldn't really make any progress.. Any help would be greatly appreciated. -mike was (Author: cambridgemike): Yep, I got that part figured out finally. Unfortunately I'm getting back 0 results when I pass the shards parameter, as opposed to when it is omited. http://localhost:8983/solr/select?q=graphmlt=truemlt.fl=titlemlt.mindf=1mlt.mintf=1fl=id,score,titleshards=localhost:8983/solr returns: lst name=moreLikeThis result name=018639b9dfd5003c20c3ceb29df9d582 numFound=0 start=0 maxScore=0.0/ result name=83de9bc1953e36e44df8e95661983183 numFound=0 start=0 maxScore=0.0/ /lst where as http://localhost:8983/solr/select?q=graphmlt=truemlt.fl=titlemlt.mindf=1mlt.mintf=1fl=id,score,title returns lst name=moreLikeThis result name=018639b9dfd5003c20c3ceb29df9d582 numFound=1198 start=0 maxScore=3.3357687/ ...result docs result name=83de9bc1953e36e44df8e95661983183 numFound=487 start=0 maxScore=4.129801/ ...result docs /lst I poked around in the code, but couldn't really make any progress.. Any help would be greatly appreciated. -mike 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] 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: Won't Fix Reverted 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: r805774 - in /lucene/solr/trunk: ./ src/common/org/apache/solr/common/params/ src/java/org/apache/solr/handler/ src/java/org/apache/solr/update/ src/solrj/org/apache/solr/client/solrj/
Noble, testExpungeDeletes fails: failure message=null type=junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:303) /failure Koji no...@apache.org wrote: Author: noble Date: Wed Aug 19 12:21:22 2009 New Revision: 805774 URL: http://svn.apache.org/viewvc?rev=805774view=rev Log: SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 Modified: lucene/solr/trunk/CHANGES.txt lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java lucene/solr/trunk/src/java/org/apache/solr/update/CommitUpdateCommand.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler2.java lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/request/UpdateRequest.java lucene/solr/trunk/src/test/org/apache/solr/update/DirectUpdateHandlerTest.java Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Wed Aug 19 12:21:22 2009 @@ -267,7 +267,9 @@ HTMLStripStandardTokenizerFactory deprecated. To strip HTML tags, HTMLStripCharFilter can be used with an arbitrary Tokenizer. (koji) -68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) +68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) + +68. SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 (noble) Optimizations Modified: lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java (original) +++ lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java Wed Aug 19 12:21:22 2009 @@ -49,4 +49,6 @@ * If optimizing, set the maximum number of segments left in the index after optimization. 1 is the default (and is equivalent to calling IndexWriter.optimize() in Lucene). */ public static final String MAX_OPTIMIZE_SEGMENTS = maxSegments; + + public static final String EXPUNGE_DELETES = expungeDeletes; } Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java Wed Aug 19 12:21:22 2009 @@ -68,6 +68,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush= params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); req.getCore().getUpdateHandler().commit( cmd ); @@ -101,6 +102,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush= params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); processor.processCommit( cmd ); return true; Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java Wed Aug 19 12:21:22 2009 @@ -155,6 +155,8 @@ sawWaitSearcher = true; } else if
[jira] Commented: (SOLR-1362) WordDelimiterFilter position increment bug
[ https://issues.apache.org/jira/browse/SOLR-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745113#action_12745113 ] Yonik Seeley commented on SOLR-1362: I could see perhaps wanting WDF to not create new gaps, but it should normally preserve existing gaps, right? In which case, a patch would be more complex than conditionally changing += to = WordDelimiterFilter position increment bug -- Key: SOLR-1362 URL: https://issues.apache.org/jira/browse/SOLR-1362 Project: Solr Issue Type: Bug Components: Analysis Reporter: Robert Muir Priority: Minor Attachments: SOLR-1362.patch WordDelimiterFilter sometimes assigns high position increment values, which inhibits phrase matches. If this is a feature and not a bug please change the issue type, and I will change the patch to propose this as an option... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SOLR-1372) Allow FieldAnalysisRequestHandler to get field value from content stream
On Aug 19, 2009, at 11:46 AM, Chris Hostetter wrote: : FieldAnalysisRequestHandler currently only allows text to be analyzed to : come from the analysis.fieldvalue parameter. It can be handy to point : Solr at a file or URL to get text also using the content stream : capability. Should we remove the analysis.fieldvalue param completely and have people use stream.body ? I thought about that... doesn't matter to me. Makes a bit more readabilty sense to have analysis.fieldvalue in the simple case. Erik
[jira] Resolved: (SOLR-1334) SortableXXXField could use native FieldCache for sorting
[ https://issues.apache.org/jira/browse/SOLR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-1334. Resolution: Won't Fix SortableXXXField could use native FieldCache for sorting Key: SOLR-1334 URL: https://issues.apache.org/jira/browse/SOLR-1334 Project: Solr Issue Type: Improvement Reporter: Uwe Schindler When looking through the FieldTypes (esp. new Trie code), I found out that field types using org.apache.solr.util.NumberUtils use String sorting. As SortField can get a FieldCache Parser since LUCENE-1478, NumberUtils could supply FieldCache.Parser singletons (serializable singletons!) for the SortableXXXField types, and the SortField instances could use these parsers instead of STRING only SortFields. The same parsers could be used to create ValueSources for these types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745116#action_12745116 ] Yonik Seeley commented on SOLR-1294: Should this patch go into 1.4? Can anyone get it to work with IE7 also? SolrJS/Javascript client fails in IE8! -- Key: SOLR-1294 URL: https://issues.apache.org/jira/browse/SOLR-1294 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Eric Pugh Attachments: SOLR-1294-IE8.patch, SOLR-1294.patch, solrjs-ie8-html-syntax-error.patch SolrJS seems to fail with 'jQuery.solrjs' is null or not an object errors under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. This happens on both the Sample online site at http://solrjs.solrstuff.org/test/reuters/ as well as the /trunk/contrib/javascript library. Seems to be a show stopper from the standpoint of really using this library! I have posted a screenshot of the error at http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png The error is just a whole bunch of repeated messages in the vein of: Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js Message: 'jQuery.solrjs' is null or not an object Line: 37 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js Message: 'jQuery.solrjs' is null or not an object Line: 24 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js Message: 'jQuery.solrjs' is null or not an object Line: 27 Char: 1 Code: 0 URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1267) relative path for dataDir in solrconfig.xml should be resolved w.r.t instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745117#action_12745117 ] Yonik Seeley commented on SOLR-1267: Will this break back compatibility with existing config files? relative path for dataDir in solrconfig.xml should be resolved w.r.t instanceDir -- Key: SOLR-1267 URL: https://issues.apache.org/jira/browse/SOLR-1267 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Attachments: SOLR-1267.patch currently , if the path given in dataDir tag is relative , it is resolved w.r.t current working directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1156) Sort TermsComponent results by frequency
[ https://issues.apache.org/jira/browse/SOLR-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745126#action_12745126 ] Yonik Seeley commented on SOLR-1156: Looks simple enough - I'll commit soon if there are no objections. Sort TermsComponent results by frequency Key: SOLR-1156 URL: https://issues.apache.org/jira/browse/SOLR-1156 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Attachments: SOLR-1156.patch, SOLR-1156.patch, SOLR-1156.patch, SOLR-1156.patch TermsComponent should be able to return results sorted by frequency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1370) call CharFilters in FieldAnalysisRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi resolved SOLR-1370. -- Resolution: Fixed Thanks Erik! Committed revision 805880. 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 Assignee: Koji Sekiguchi Priority: Minor Fix For: 1.4 Attachments: SOLR-1370.patch 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.
Re: svn commit: r805774 - in /lucene/solr/trunk: ./ src/common/org/apache/solr/common/params/ src/java/org/apache/solr/handler/ src/java/org/apache/solr/update/ src/solrj/org/apache/solr/client/solr
Hello! Same here, assertion fails on our hudson. On Wed, Aug 19, 2009 at 10:07 PM, Koji Sekiguchik...@r.email.ne.jp wrote: Noble, testExpungeDeletes fails: oh . It passed twice in my box.is any one else noticing this failure? failure message=null type=junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:303) /failure Koji no...@apache.org wrote: Author: noble Date: Wed Aug 19 12:21:22 2009 New Revision: 805774 URL: http://svn.apache.org/viewvc?rev=805774view=rev Log: SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 Modified: lucene/solr/trunk/CHANGES.txt lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java lucene/solr/trunk/src/java/org/apache/solr/update/CommitUpdateCommand.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler2.java lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/request/UpdateRequest.java lucene/solr/trunk/src/test/org/apache/solr/update/DirectUpdateHandlerTest.java Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Wed Aug 19 12:21:22 2009 @@ -267,7 +267,9 @@ HTMLStripStandardTokenizerFactory deprecated. To strip HTML tags, HTMLStripCharFilter can be used with an arbitrary Tokenizer. (koji) -68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) +68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) + +68. SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 (noble) Optimizations Modified: lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java (original) +++ lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java Wed Aug 19 12:21:22 2009 @@ -49,4 +49,6 @@ * If optimizing, set the maximum number of segments left in the index after optimization. 1 is the default (and is equivalent to calling IndexWriter.optimize() in Lucene). */ public static final String MAX_OPTIMIZE_SEGMENTS = maxSegments; + + public static final String EXPUNGE_DELETES = expungeDeletes; } Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java Wed Aug 19 12:21:22 2009 @@ -68,6 +68,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); req.getCore().getUpdateHandler().commit( cmd ); @@ -101,6 +102,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); processor.processCommit( cmd ); return true; Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java?rev=805774r1=805773r2=805774view=diff == ---
[jira] Reopened: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reopened SOLR-1275: -- 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.
Re: svn commit: r805774 - in /lucene/solr/trunk: ./ src/common/org/apache/solr/common/params/ src/java/org/apache/solr/handler/ src/java/org/apache/solr/update/ src/solrj/org/apache/solr/client/solr
On Wed, Aug 19, 2009 at 10:07 PM, Koji Sekiguchik...@r.email.ne.jp wrote: Noble, testExpungeDeletes fails: oh . It passed twice in my box.is any one else noticing this failure? failure message=null type=junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:303) /failure Koji no...@apache.org wrote: Author: noble Date: Wed Aug 19 12:21:22 2009 New Revision: 805774 URL: http://svn.apache.org/viewvc?rev=805774view=rev Log: SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 Modified: lucene/solr/trunk/CHANGES.txt lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java lucene/solr/trunk/src/java/org/apache/solr/update/CommitUpdateCommand.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler2.java lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/request/UpdateRequest.java lucene/solr/trunk/src/test/org/apache/solr/update/DirectUpdateHandlerTest.java Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Wed Aug 19 12:21:22 2009 @@ -267,7 +267,9 @@ HTMLStripStandardTokenizerFactory deprecated. To strip HTML tags, HTMLStripCharFilter can be used with an arbitrary Tokenizer. (koji) -68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) +68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) + +68. SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 (noble) Optimizations Modified: lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java (original) +++ lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java Wed Aug 19 12:21:22 2009 @@ -49,4 +49,6 @@ * If optimizing, set the maximum number of segments left in the index after optimization. 1 is the default (and is equivalent to calling IndexWriter.optimize() in Lucene). */ public static final String MAX_OPTIMIZE_SEGMENTS = maxSegments; + + public static final String EXPUNGE_DELETES = expungeDeletes; } Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java Wed Aug 19 12:21:22 2009 @@ -68,6 +68,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); req.getCore().getUpdateHandler().commit( cmd ); @@ -101,6 +102,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); processor.processCommit( cmd ); return true; Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java (original) +++
[jira] Commented: (SOLR-1267) relative path for dataDir in solrconfig.xml should be resolved w.r.t instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745121#action_12745121 ] Noble Paul commented on SOLR-1267: -- bq.Will this break back compatibility with existing config files? Yes. But the current behavior is a bug. resolving w.r.t current working directory is so arbitrary. Shhould we mark this for 1.4? relative path for dataDir in solrconfig.xml should be resolved w.r.t instanceDir -- Key: SOLR-1267 URL: https://issues.apache.org/jira/browse/SOLR-1267 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Attachments: SOLR-1267.patch currently , if the path given in dataDir tag is relative , it is resolved w.r.t current working directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745128#action_12745128 ] Noble Paul commented on SOLR-1275: -- the testcase fails 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] Resolved: (SOLR-1109) PhoneticFilterFactory doesn't handle maxCodeLength param
[ https://issues.apache.org/jira/browse/SOLR-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-1109. Resolution: Fixed Fix Version/s: 1.4 PhoneticFilterFactory doesn't handle maxCodeLength param Key: SOLR-1109 URL: https://issues.apache.org/jira/browse/SOLR-1109 Project: Solr Issue Type: Bug Reporter: Yonik Seeley Priority: Minor Fix For: 1.4 Attachments: SOLR-1109.patch An exception is thrown when the maxCodeLength attribute is used on PhoneticFilterFactory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1103) LukeRequestHandler histogram excludes freq of 1
[ https://issues.apache.org/jira/browse/SOLR-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745131#action_12745131 ] Yonik Seeley commented on SOLR-1103: Should this be fixed for 1.4? LukeRequestHandler histogram excludes freq of 1 --- Key: SOLR-1103 URL: https://issues.apache.org/jira/browse/SOLR-1103 Project: Solr Issue Type: Bug Reporter: Hoss Man Priority: Minor the TermHistogram class in the LukeRequestHandler seems to properly count the occurances of terms with a freq of 1, but then when converting to a NamedLIst begins iterating at bucket 2 so the counts for freq of 1 don't appear in the result. this may have been a conscious choice to eliminate superfluously high values for terms with a freq of one ... or it may have been a mistake assuming freq values of 1 would fall in the 2 bucket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745135#action_12745135 ] Noble Paul commented on SOLR-1275: -- committed r805888 The test passes now. 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.
Re: svn commit: r805774 - in /lucene/solr/trunk: ./ src/common/org/apache/solr/common/params/ src/java/org/apache/solr/handler/ src/java/org/apache/solr/update/ src/solrj/org/apache/solr/client/solr
I'm looking into it. I guess I goofed up somewhere 2009/8/19 Rafał Kuć ra...@alud.com.pl: Hello! Same here, assertion fails on our hudson. On Wed, Aug 19, 2009 at 10:07 PM, Koji Sekiguchik...@r.email.ne.jp wrote: Noble, testExpungeDeletes fails: oh . It passed twice in my box.is any one else noticing this failure? failure message=null type=junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:303) /failure Koji no...@apache.org wrote: Author: noble Date: Wed Aug 19 12:21:22 2009 New Revision: 805774 URL: http://svn.apache.org/viewvc?rev=805774view=rev Log: SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 Modified: lucene/solr/trunk/CHANGES.txt lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java lucene/solr/trunk/src/java/org/apache/solr/update/CommitUpdateCommand.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler2.java lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/request/UpdateRequest.java lucene/solr/trunk/src/test/org/apache/solr/update/DirectUpdateHandlerTest.java Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Wed Aug 19 12:21:22 2009 @@ -267,7 +267,9 @@ HTMLStripStandardTokenizerFactory deprecated. To strip HTML tags, HTMLStripCharFilter can be used with an arbitrary Tokenizer. (koji) -68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) +68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) + +68. SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 (noble) Optimizations Modified: lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java (original) +++ lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java Wed Aug 19 12:21:22 2009 @@ -49,4 +49,6 @@ * If optimizing, set the maximum number of segments left in the index after optimization. 1 is the default (and is equivalent to calling IndexWriter.optimize() in Lucene). */ public static final String MAX_OPTIMIZE_SEGMENTS = maxSegments; + + public static final String EXPUNGE_DELETES = expungeDeletes; } Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java Wed Aug 19 12:21:22 2009 @@ -68,6 +68,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); req.getCore().getUpdateHandler().commit( cmd ); @@ -101,6 +102,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); processor.processCommit( cmd ); return true; Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java?rev=805774r1=805773r2=805774view=diff
[jira] Updated: (SOLR-1103) LukeRequestHandler histogram excludes freq of 1
[ https://issues.apache.org/jira/browse/SOLR-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1103: --- Fix Version/s: 1.4 yeah ... fixing should be trivial, i just wasn't sure where the bug was (the iteration, or the bucket assignment) LukeRequestHandler histogram excludes freq of 1 --- Key: SOLR-1103 URL: https://issues.apache.org/jira/browse/SOLR-1103 Project: Solr Issue Type: Bug Reporter: Hoss Man Priority: Minor Fix For: 1.4 the TermHistogram class in the LukeRequestHandler seems to properly count the occurances of terms with a freq of 1, but then when converting to a NamedLIst begins iterating at bucket 2 so the counts for freq of 1 don't appear in the result. this may have been a conscious choice to eliminate superfluously high values for terms with a freq of one ... or it may have been a mistake assuming freq values of 1 would fall in the 2 bucket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745150#action_12745150 ] Noble Paul commented on SOLR-1275: -- The tests are passing ,but for the time being I wish to keep this open . Let us review the change in DUH2#commit() once again and ensure that the fix is right 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] Updated: (SOLR-1369) Add HSQLDB Jar to example-dih
[ https://issues.apache.org/jira/browse/SOLR-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1369: Component/s: contrib - DataImportHandler Add HSQLDB Jar to example-dih - Key: SOLR-1369 URL: https://issues.apache.org/jira/browse/SOLR-1369 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler 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.
Re: svn commit: r805774 - in /lucene/solr/trunk: ./ src/common/org/apache/solr/common/params/ src/java/org/apache/solr/handler/ src/java/org/apache/solr/update/ src/solrj/org/apache/solr/client/solr
OK, now the problem is gone. Koji Noble Paul നോബിള് नोब्ळ् wrote: I'm looking into it. I guess I goofed up somewhere 2009/8/19 Rafał Kuć ra...@alud.com.pl: Hello! Same here, assertion fails on our hudson. On Wed, Aug 19, 2009 at 10:07 PM, Koji Sekiguchik...@r.email.ne.jp wrote: Noble, testExpungeDeletes fails: oh . It passed twice in my box.is any one else noticing this failure? failure message=null type=junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:303) /failure Koji no...@apache.org wrote: Author: noble Date: Wed Aug 19 12:21:22 2009 New Revision: 805774 URL: http://svn.apache.org/viewvc?rev=805774view=rev Log: SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 Modified: lucene/solr/trunk/CHANGES.txt lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java lucene/solr/trunk/src/java/org/apache/solr/update/CommitUpdateCommand.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler2.java lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/request/UpdateRequest.java lucene/solr/trunk/src/test/org/apache/solr/update/DirectUpdateHandlerTest.java Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Wed Aug 19 12:21:22 2009 @@ -267,7 +267,9 @@ HTMLStripStandardTokenizerFactory deprecated. To strip HTML tags, HTMLStripCharFilter can be used with an arbitrary Tokenizer. (koji) -68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) +68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) + +68. SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 (noble) Optimizations Modified: lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java (original) +++ lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java Wed Aug 19 12:21:22 2009 @@ -49,4 +49,6 @@ * If optimizing, set the maximum number of segments left in the index after optimization. 1 is the default (and is equivalent to calling IndexWriter.optimize() in Lucene). */ public static final String MAX_OPTIMIZE_SEGMENTS = maxSegments; + + public static final String EXPUNGE_DELETES = expungeDeletes; } Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java Wed Aug 19 12:21:22 2009 @@ -68,6 +68,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush= params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); req.getCore().getUpdateHandler().commit( cmd ); @@ -101,6 +102,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush= params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); processor.processCommit( cmd ); return true; Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java?rev=805774r1=805773r2=805774view=diff
[jira] Commented: (SOLR-1369) Add HSQLDB Jar to example-dih
[
https://issues.apache.org/jira/browse/SOLR-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745152#action_12745152
]
Shalin Shekhar Mangar commented on SOLR-1369:
-
{quote}
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.
{quote}
Sure
{quote}
2) include hsqldb.jar in the example. I am assuming the reason this wasn't done
was because of licensing issues??
{quote}
I don't remember too well. It may have been the license. We can check with
legal on the license.
{quote}
Also, any real reason to zip the hsqldb database? It's under 20k expanded and
adds another step.
{quote}
Yeah, I guess we can leave it expanded.
Add HSQLDB Jar to example-dih
-
Key: SOLR-1369
URL: https://issues.apache.org/jira/browse/SOLR-1369
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
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.
Re: svn commit: r805774 - in /lucene/solr/trunk: ./ src/common/org/apache/solr/common/params/ src/java/org/apache/solr/handler/ src/java/org/apache/solr/update/ src/solrj/org/apache/solr/client/solr
It's could be due to CMS so I'll create a config with SMS, run 10 times and see if it fails. On Wed, Aug 19, 2009 at 10:59 AM, Koji Sekiguchik...@r.email.ne.jp wrote: OK, now the problem is gone. Koji Noble Paul നോബിള് नोब्ळ् wrote: I'm looking into it. I guess I goofed up somewhere 2009/8/19 Rafał Kuć ra...@alud.com.pl: Hello! Same here, assertion fails on our hudson. On Wed, Aug 19, 2009 at 10:07 PM, Koji Sekiguchik...@r.email.ne.jp wrote: Noble, testExpungeDeletes fails: oh . It passed twice in my box.is any one else noticing this failure? failure message=null type=junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:303) /failure Koji no...@apache.org wrote: Author: noble Date: Wed Aug 19 12:21:22 2009 New Revision: 805774 URL: http://svn.apache.org/viewvc?rev=805774view=rev Log: SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 Modified: lucene/solr/trunk/CHANGES.txt lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java lucene/solr/trunk/src/java/org/apache/solr/update/CommitUpdateCommand.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler2.java lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/request/UpdateRequest.java lucene/solr/trunk/src/test/org/apache/solr/update/DirectUpdateHandlerTest.java Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Wed Aug 19 12:21:22 2009 @@ -267,7 +267,9 @@ HTMLStripStandardTokenizerFactory deprecated. To strip HTML tags, HTMLStripCharFilter can be used with an arbitrary Tokenizer. (koji) -68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) +68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) + +68. SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 (noble) Optimizations Modified: lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java (original) +++ lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java Wed Aug 19 12:21:22 2009 @@ -49,4 +49,6 @@ * If optimizing, set the maximum number of segments left in the index after optimization. 1 is the default (and is equivalent to calling IndexWriter.optimize() in Lucene). */ public static final String MAX_OPTIMIZE_SEGMENTS = maxSegments; + + public static final String EXPUNGE_DELETES = expungeDeletes; } Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java Wed Aug 19 12:21:22 2009 @@ -68,6 +68,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); req.getCore().getUpdateHandler().commit( cmd ); @@ -101,6 +102,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); processor.processCommit( cmd );
Fwd: [Solr Wiki] Trivial Update of HowToRelease by YonikSeeley
Begin forwarded message: From: Apache Wiki wikidi...@apache.org Date: August 18, 2009 1:55:59 PM EDT To: solr-comm...@lucene.apache.org Subject: [Solr Wiki] Trivial Update of HowToRelease by YonikSeeley Reply-To: solr-dev@lucene.apache.org Dear Wiki user, You have subscribed to a wiki page or wiki category on Solr Wiki for change notification. The following page has been changed by YonikSeeley: http://wiki.apache.org/solr/HowToRelease The comment on the change is: emphasise that things don't have to be done this way -- + This page is to help a Solr committer create a new release (you need committer rights for some of the steps to create an official release). It does not reflect official release policy - many of the items may be optional, or may be modified as necessary. - ''This page is prepared for Solr committers. You need committer rights - to create a new Solr release.'' I really don't think this is a good idea. What gets released and how it gets released should not be up to the RM. We as a community have agreed to support the artifacts we produce. One individual should not then get to undermine that b/c they don't have a particular use for some particular artifact or release step.
Re: svn commit: r805774 - in /lucene/solr/trunk: ./ src/common/org/apache/solr/common/params/ src/java/org/apache/solr/handler/ src/java/org/apache/solr/update/ src/solrj/org/apache/solr/client/solr
Fails consistently with SMS so I'll post a new patch shortly. On Wed, Aug 19, 2009 at 11:31 AM, Jason Rutherglenjason.rutherg...@gmail.com wrote: It's could be due to CMS so I'll create a config with SMS, run 10 times and see if it fails. On Wed, Aug 19, 2009 at 10:59 AM, Koji Sekiguchik...@r.email.ne.jp wrote: OK, now the problem is gone. Koji Noble Paul നോബിള് नोब्ळ् wrote: I'm looking into it. I guess I goofed up somewhere 2009/8/19 Rafał Kuć ra...@alud.com.pl: Hello! Same here, assertion fails on our hudson. On Wed, Aug 19, 2009 at 10:07 PM, Koji Sekiguchik...@r.email.ne.jp wrote: Noble, testExpungeDeletes fails: oh . It passed twice in my box.is any one else noticing this failure? failure message=null type=junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at org.apache.solr.update.DirectUpdateHandlerTest.testExpungeDeletes(DirectUpdateHandlerTest.java:303) /failure Koji no...@apache.org wrote: Author: noble Date: Wed Aug 19 12:21:22 2009 New Revision: 805774 URL: http://svn.apache.org/viewvc?rev=805774view=rev Log: SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 Modified: lucene/solr/trunk/CHANGES.txt lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java lucene/solr/trunk/src/java/org/apache/solr/handler/XMLLoader.java lucene/solr/trunk/src/java/org/apache/solr/update/CommitUpdateCommand.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler.java lucene/solr/trunk/src/java/org/apache/solr/update/DirectUpdateHandler2.java lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/request/UpdateRequest.java lucene/solr/trunk/src/test/org/apache/solr/update/DirectUpdateHandlerTest.java Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Wed Aug 19 12:21:22 2009 @@ -267,7 +267,9 @@ HTMLStripStandardTokenizerFactory deprecated. To strip HTML tags, HTMLStripCharFilter can be used with an arbitrary Tokenizer. (koji) -68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) +68. SOLR-1367: Added callback mechanism for converting DocList to SolrDocumentList in SolrPluginUtils (gsingers) + +68. SOLR-1275: Add expungeDeletes to DirectUpdateHandler2 (noble) Optimizations Modified: lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java (original) +++ lucene/solr/trunk/src/common/org/apache/solr/common/params/UpdateParams.java Wed Aug 19 12:21:22 2009 @@ -49,4 +49,6 @@ * If optimizing, set the maximum number of segments left in the index after optimization. 1 is the default (and is equivalent to calling IndexWriter.optimize() in Lucene). */ public static final String MAX_OPTIMIZE_SEGMENTS = maxSegments; + + public static final String EXPUNGE_DELETES = expungeDeletes; } Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java?rev=805774r1=805773r2=805774view=diff == --- lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java (original) +++ lucene/solr/trunk/src/java/org/apache/solr/handler/RequestHandlerUtils.java Wed Aug 19 12:21:22 2009 @@ -68,6 +68,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes); cmd.maxOptimizeSegments = params.getInt(UpdateParams.MAX_OPTIMIZE_SEGMENTS, cmd.maxOptimizeSegments); req.getCore().getUpdateHandler().commit( cmd ); @@ -101,6 +102,7 @@ CommitUpdateCommand cmd = new CommitUpdateCommand( optimize ); cmd.waitFlush = params.getBool( UpdateParams.WAIT_FLUSH, cmd.waitFlush ); cmd.waitSearcher = params.getBool( UpdateParams.WAIT_SEARCHER, cmd.waitSearcher ); + cmd.expungeDeletes = params.getBool( UpdateParams.EXPUNGE_DELETES, cmd.expungeDeletes);
[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 solrconfig-serialms.xml which uses a SerialMergeScheduler (instead of ConcurrentMergeScheduler). Otherwise we get inconsistent numbers of segments at variable times (because the merging is happening asynchronously) * Commit is called every 500 docs to insure we get enough segments * Test passes 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, 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] Created: (SOLR-1373) Add filter query in solr/admin/form.jsp
Add filter query in solr/admin/form.jsp --- Key: SOLR-1373 URL: https://issues.apache.org/jira/browse/SOLR-1373 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 1.4 Reporter: Jason Rutherglen Priority: Trivial Fix For: 1.5 The full interface needs a filter query text field. -- 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-tabpanelfocusedCommentId=12745212#action_12745212
]
Shalin Shekhar Mangar commented on SOLR-1371:
-
bq. any objections to me committing this before 1.4?
Nope, please go ahead.
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-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 ] Shalin Shekhar Mangar updated SOLR-1366: Component/s: replication (java) 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: replication (java), 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] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745214#action_12745214 ] Yonik Seeley commented on SOLR-1275: The standard solrconfig.xml in the test directory has a LogDocMergePolicy and maxBufferedDocs=10 to generate more segments. In some other Solr tests, I add a few docs, then do a commit, add a few docs, then do another commit to get 2 segments for example. Shouldn't that work to get a fixed number of segments? 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, 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-1172) Hyphenation in Query Boost Function
[
https://issues.apache.org/jira/browse/SOLR-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745241#action_12745241
]
Trey commented on SOLR-1172:
I've encountered this issue in another context. It is being caused by invalid
parsing of Function Queries:
The following query works fine (field name: rank_i):
/solr/select/?q.op=ANDstart=0rows=10fl=*%2cscoreq={!func}product(rank_i,2)
But the following query (field name: rank-i) throws a Parse Error (returns 404):
q={!func}product(rank-i,2)
Here's the error:
HTTP ERROR: 400
org.apache.lucene.queryParser.ParseException: Expected ',' at position 14 in
'product(rank_i,2)'
I confirmed that the problem occurs whenever a hyphen/minus/dash occurs in the
field name by putting in a fake field name:
q={!func}product(MadeUpField-Name,2)
HTTP ERROR: 400
undefined field MadeUpField
So, it looks like it is trying to parse the - in the field name as an
operator instead of as part of the field name. Is it bad form to include a
hyphen in a field name... I've never had issues with it anywhere else in the
past. FYI, I've confirmed this behavior on 1.4 nightly builds from both 6/16
and 8/6 and both forms of the function query syntax ({!func} and _val_). Also,
I have this problem with seemingly all function queries (ord, sum, etc.), not
just product.
Hyphenation in Query Boost Function
---
Key: SOLR-1172
URL: https://issues.apache.org/jira/browse/SOLR-1172
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3
Environment: Windows, PC
Reporter: Yao Ge
I have a field named last-modified that I like to use in bf (Boot
Functions) parameter: recip(rord(last-modified),1,1000,1000) in
DisMaxRequestHander.
However the Solr query parser complain about the syntax of the formula.
{quote}
The request sent by the client was syntactically incorrect
(org.apache.lucene.queryParser.ParseException: Expected identifier at pos 11
str='recip(rord(last-modified),1,1000,1000)').
{quote}
{code}
SEVERE: org.apache.solr.common.SolrException:
org.apache.lucene.queryParser.ParseException: Expected identifier at pos 11
str='recip(rord(last-modified),1,1000,1000)'
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:101)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:148)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.lucene.queryParser.ParseException: Expected identifier
at pos 11 str='recip(rord(last-modified),1,1000,1000)'
at
org.apache.solr.search.QueryParsing$StrParser.getId(QueryParsing.java:565)
at
org.apache.solr.search.FunctionQParser.parseId(FunctionQParser.java:73)
at
org.apache.solr.search.ValueSourceParser$2.parse(ValueSourceParser.java:79)
at
org.apache.solr.search.FunctionQParser.parseValueSource(FunctionQParser.java:187)
at
org.apache.solr.search.FunctionQParser.parseValueSource(FunctionQParser.java:113)
at
org.apache.solr.search.ValueSourceParser$5.parse(ValueSourceParser.java:112)
at
org.apache.solr.search.FunctionQParser.parseValueSource(FunctionQParser.java:187)
at
org.apache.solr.search.FunctionQParser.parseValueSource(FunctionQParser.java:113)
at
[jira] Issue Comment Edited: (SOLR-422) one double quote or two double quotes only break search
[ https://issues.apache.org/jira/browse/SOLR-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745245#action_12745245 ] Trey Grainger edited comment on SOLR-422 at 8/19/09 5:03 PM: - This issue is in the same ballpark as SOLR-874. Both concern bad parsing of fringe cases by the DisMax handler. was (Author: tgrainger): This issue is in the same ballpark as SOLR-878. Both concern bad parsing of fringe cases by the DisMax handler. one double quote or two double quotes only break search --- Key: SOLR-422 URL: https://issues.apache.org/jira/browse/SOLR-422 Project: Solr Issue Type: Bug Components: search Reporter: Doug Daniels Priority: Minor Using Dismax, searching for either one double quote character: q= or two double quote characters with no text between them: q= throws an exception. Not sure whether this is also the case for other request handlers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745249#action_12745249 ] Jason Rutherglen commented on SOLR-1275: Because maxBufferedDocs=10, and the previous patch was creating 3000 docs, a lot of merging was happening in the background. SMS gives predictable merging for any number of documents which is more suitable for testing. 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, 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] Updated: (SOLR-422) one double quote or two double quotes only break search
[ https://issues.apache.org/jira/browse/SOLR-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Grainger updated SOLR-422: --- Comment: was deleted (was: This issue is in the same ballpark as SOLR-874. Both concern bad parsing of fringe cases by the DisMax handler.) one double quote or two double quotes only break search --- Key: SOLR-422 URL: https://issues.apache.org/jira/browse/SOLR-422 Project: Solr Issue Type: Bug Components: search Reporter: Doug Daniels Priority: Minor Using Dismax, searching for either one double quote character: q= or two double quote characters with no text between them: q= throws an exception. Not sure whether this is also the case for other request handlers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-422) one double quote or two double quotes only break search
[ https://issues.apache.org/jira/browse/SOLR-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Grainger updated SOLR-422: --- Comment: was deleted (was: These issues both concern reworking of the Dismax parser to handle fringe cases and should be dealt with together.) one double quote or two double quotes only break search --- Key: SOLR-422 URL: https://issues.apache.org/jira/browse/SOLR-422 Project: Solr Issue Type: Bug Components: search Reporter: Doug Daniels Priority: Minor Using Dismax, searching for either one double quote character: q= or two double quote characters with no text between them: q= throws an exception. Not sure whether this is also the case for other request handlers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DataImportHandler - very slow delta import
We have refrained from putting in any intelligence in DIH in
constructing queries. It is not wise to put in something which is
useful to somebody but breaks at lot of the cases. This is a support
nightmare. Our intent is to help user construct the query himself so
that there are few surprises
On Thu, Aug 20, 2009 at 3:24 AM, Matthew
Paintermatthew.pain...@archives.govt.nz wrote:
Fair enough; I was wondering if that was the reason. Although, wouldn't the
vast majority of delta queries be covered by standard 'in' clause syntax? e.g.
select * from myTable where id in (1,2,3,...)
I'm just wondering whether that could be adopted as the standard behaviour,
with the simpleton approach available as an option for more complex queries.
I can see though that this may well be fraught with peril!
Anyway, thanks for your help - it's much appreciated.
M
-Original Message-
From: noble.p...@gmail.com [mailto:noble.p...@gmail.com] On Behalf Of Noble
Paul ??? ??
Sent: Wednesday, 19 August 2009 5:52 p.m.
To: Matthew Painter
Subject: Re: DataImportHandler - very slow delta import
On Wed, Aug 19, 2009 at 3:15 AM, Matthew
Paintermatthew.pain...@archives.govt.nz wrote:
Thanks; that confirms my observed behaviour.
However, why would the delta query have to make a single db call per changed
row? For simple delta queries like mine below, batching a chunk of rows at
the time from the database seems quite doable. Or are there less-trivial
situations where batching wouldn't work?
The problem is that DIH cannot create intelligent queries but the users can .
So DIH goes with the simpleton approach of
for each row returned by deltaQuery run the deltaImportQuery.
Does the deletedPkQuery suffer from the same performance issues? The problem
in our specific instance is that often we're removing and modifying
thousands of rows in one hit so I may have to adopt a different approach.
I'm not comfortable using Solr 1.4 in a production environment yet, so
unfortunately the nice new features in the DataImportHandler aren't an
option.
deletedPkQuery has no such problem because it is run only once
I'll try your suggested solution soon.
M
-Original Message-
From: noble.p...@gmail.com [mailto:noble.p...@gmail.com] On Behalf Of Noble
Paul ??? ??
Sent: Tuesday, 18 August 2009 5:11 p.m.
To: solr-u...@lucene.apache.org
Subject: Re: DataImportHandler - very slow delta import
delta imports are likely to be far slower that the full imports
because it makes one db call per changed row. if you can write the
query in such a way that it gives only the changed rows, then write
a separate entity (directly under document) and just run a
full-import with that entity only.
On Tue, Aug 18, 2009 at 6:32 AM, Matthew
Paintermatthew.pain...@archives.govt.nz wrote:
Hi,
We are using Solr's DataImportHandler to populate the Solr index from
a SQL Server database of nearly 4,000,000 rows. Whereas the
population itself is very fast (around 1000 rows per second), the
delta import is only processing around one row a second.
Is this a known performance issue? We are using Solr 1.3.
For reference, the abridged entity configuration (cuts indicated by
'...') is below:
entity name=id transformer=ClobTransformer pk=oid
query=select archwaypublic.getSolrIdentifier(oid,
'agency') as oid, oid as realoid,
archwaypublic.getSolrIdentifier(oid, 'agency') as id, code, name, ...
deltaQuery=select oid from publicagency with (nolock) where
modifiedtime '${dataimporter.last_index_time}'
deletedPkQuery=select archwaypublic.getSolrIdentifier(entityoid,
'agency') as oid from pendingsolrdeletions with (nolock) where
entitytype='agency'
...
/entity
Thanks,
Matt
This e-mail message and any attachments are CONFIDENTIAL to the
addressee(s) and may also be LEGALLY PRIVILEGED. If you are not the
intended addressee, please do not use, disclose, copy or distribute the
message or the information it contains. Instead, please notify me as soon
as possible and delete the e-mail, including any attachments. Thank you.
--
-
Noble Paul | Principal Engineer| AOL | http://aol.com This e-mail
message and any attachments are CONFIDENTIAL to the addressee(s) and may
also be LEGALLY PRIVILEGED. If you are not the intended addressee, please
do not use, disclose, copy or distribute the message or the information it
contains. Instead, please notify me as soon as possible and delete the
e-mail, including any attachments. Thank you.
--
-
Noble Paul | Principal Engineer| AOL | http://aol.com
This e-mail message and any attachments are CONFIDENTIAL to the addressee(s)
and may also be LEGALLY PRIVILEGED. If you are not the intended addressee,
please do not use, disclose, copy or distribute the message or the
information
