Re: facet.sort parameter
if i'm understanding you: you're really just suggesting a syntactic change, correct? true becomes count and false becomes lex ? Yes. For now, it would be just that. In the future I guess there'll probably be more ways to sort. (the slightly tricky thing is making it a string param but ensureing stuff continues to work for people who use bool name=facet.sorttrue/bool to set the params using default configs without getting into ClassCast/instanceOf nightmares) Ah, I didn't think about that. I guess there's nothing we can really do about that but maybe warn though. I'll give it some thought. Lars
[jira] Updated: (SOLR-617) Allow configurable deletion policy
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akshay K. Ukey updated SOLR-617:
Attachment: solr-617.patch
Patch with test cases and in sync with trunk.
Allow configurable deletion policy
--
Key: SOLR-617
URL: https://issues.apache.org/jira/browse/SOLR-617
Project: Solr
Issue Type: New Feature
Components: search, update
Affects Versions: 1.4
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.4
Attachments: 617.patch, solr-617.patch, solr-617.patch, solr-617.patch
Lucene API provides means to configure deletion policy. Solr should be able
to expose it through configuration in solrconfig.xml. Moreover the new
replication (SOLR-561) strategy is going to rely on this .
I propose the configuration go into the mainIndex section
sample configuration
{code:xml|title=solrconfig.xml}
mainIndex
!-- configure deletion policy here--
deletionPolicy
!-- Store only the commits with optimize.Non optimized commits will
get deleted by lucene when
the last IndexWriter/IndexReader using this commit point is
closed --
keepOptimizedOnlytrue/keepOptimizedOnly
!--Maximum no: of commit points stored . Older ones will be cleaned
when they go out of scope--
maxCommitsToKeep/maxCommitsToKeep
!-- max age of a stored commit--
maxCommitAge/maxCommitAge
/deletionPolicy
/mainIndex
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Solr-trunk #574
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/574/changes -- started Building remotely on lucene.zones.apache.org ERROR: svn: timed out waiting for server svn: OPTIONS request failed on '/repos/asf/lucene/solr/trunk' org.tmatesoft.svn.core.SVNException: svn: timed out waiting for server svn: OPTIONS request failed on '/repos/asf/lucene/solr/trunk' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:102) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:86) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:545) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:255) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:243) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:452) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:95) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:642) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:95) at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1308) at hudson.scm.SubversionSCM.repositoryLocationsExist(SubversionSCM.java:1369) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:357) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:321) at hudson.model.AbstractProject.checkout(AbstractProject.java:631) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:260) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:234) at hudson.model.Run.run(Run.java:791) at hudson.model.Build.run(Build.java:84) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:88) Caused by: java.net.SocketTimeoutException: connect timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:53) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:165) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:302) ... 17 more Publishing Javadoc Recording test results Publishing Clover coverage report... Publishing Clover coverage results...
[jira] Issue Comment Edited: (SOLR-617) Allow configurable deletion policy
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633649#action_12633649
]
akshay edited comment on SOLR-617 at 9/23/08 1:13 AM:
--
This patch has:
1. maxCommitAge configuration support
2. Reservation mechanism is added in the ReplicationHandler configuration. Code
for the same is in the latest patch of
https://issues.apache.org/jira/browse/SOLR-561
3. Test cases.
was (Author: akshay):
Patch with test cases and in sync with trunk.
Allow configurable deletion policy
--
Key: SOLR-617
URL: https://issues.apache.org/jira/browse/SOLR-617
Project: Solr
Issue Type: New Feature
Components: search, update
Affects Versions: 1.4
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.4
Attachments: 617.patch, solr-617.patch, solr-617.patch, solr-617.patch
Lucene API provides means to configure deletion policy. Solr should be able
to expose it through configuration in solrconfig.xml. Moreover the new
replication (SOLR-561) strategy is going to rely on this .
I propose the configuration go into the mainIndex section
sample configuration
{code:xml|title=solrconfig.xml}
mainIndex
!-- configure deletion policy here--
deletionPolicy
!-- Store only the commits with optimize.Non optimized commits will
get deleted by lucene when
the last IndexWriter/IndexReader using this commit point is
closed --
keepOptimizedOnlytrue/keepOptimizedOnly
!--Maximum no: of commit points stored . Older ones will be cleaned
when they go out of scope--
maxCommitsToKeep/maxCommitsToKeep
!-- max age of a stored commit--
maxCommitAge/maxCommitAge
/deletionPolicy
/mainIndex
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Solr nightly build failure
BUILD FAILED /tmp/build.xml:38: Cannot find ../build-contrib.xml imported from /tmp/build.xml Total time: 1 second
[jira] Created: (SOLR-786) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser
refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser -- Key: SOLR-786 URL: https://issues.apache.org/jira/browse/SOLR-786 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3, 1.3.1, 1.4 Reporter: Wojciech Biela Fix For: 1.3.1 I needed to change some of the default behaviour of the DismaxQParser, so as opposed to infecting the solr codebase with our custom behaviour, I wanted to be able to subclass the DismaxQParser and change only what we wanted to change. Here I submit a patch that allows for such subclassing. The change that is done to the code base in the following steps: 1. refactor in the DismaxQParser.parse() method to addMainQuery(query, solrParams); addBoostQuery(query, solrParams); addBoostFunctions(query, solrParams); 2. refactor the addMainQuery() method to use getUserQuery(userQuery, up, solrParams) getAlternateUserQuery(solrParams) getPhraseQuery(userQuery, pp) 3. move the DismaxQParser to the top-level to make it public (and allow subclassing) After applying this change I can to as follows: 1. write my own QParserPlugin to return a subclass of the DismaxQParser 2. in this subclass I override the the methods I need, in my case the getUserQuery() method. 3. add this plugin to the solrconfig.xml and use it the patch is done against the Solr svn trunk -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-786) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser
[ https://issues.apache.org/jira/browse/SOLR-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Biela updated SOLR-786: Attachment: dismax-query-parser.patch the patch refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser -- Key: SOLR-786 URL: https://issues.apache.org/jira/browse/SOLR-786 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3, 1.3.1, 1.4 Reporter: Wojciech Biela Fix For: 1.3.1 Attachments: dismax-query-parser.patch I needed to change some of the default behaviour of the DismaxQParser, so as opposed to infecting the solr codebase with our custom behaviour, I wanted to be able to subclass the DismaxQParser and change only what we wanted to change. Here I submit a patch that allows for such subclassing. The change that is done to the code base in the following steps: 1. refactor in the DismaxQParser.parse() method to addMainQuery(query, solrParams); addBoostQuery(query, solrParams); addBoostFunctions(query, solrParams); 2. refactor the addMainQuery() method to use getUserQuery(userQuery, up, solrParams) getAlternateUserQuery(solrParams) getPhraseQuery(userQuery, pp) 3. move the DismaxQParser to the top-level to make it public (and allow subclassing) After applying this change I can to as follows: 1. write my own QParserPlugin to return a subclass of the DismaxQParser 2. in this subclass I override the the methods I need, in my case the getUserQuery() method. 3. add this plugin to the solrconfig.xml and use it the patch is done against the Solr svn trunk -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-786) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser
[ https://issues.apache.org/jira/browse/SOLR-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Biela updated SOLR-786: Priority: Minor (was: Major) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser -- Key: SOLR-786 URL: https://issues.apache.org/jira/browse/SOLR-786 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3, 1.3.1, 1.4 Reporter: Wojciech Biela Priority: Minor Fix For: 1.3.1 Attachments: dismax-query-parser.patch I needed to change some of the default behaviour of the DismaxQParser, so as opposed to infecting the solr codebase with our custom behaviour, I wanted to be able to subclass the DismaxQParser and change only what we wanted to change. Here I submit a patch that allows for such subclassing. The change that is done to the code base in the following steps: 1. refactor in the DismaxQParser.parse() method to addMainQuery(query, solrParams); addBoostQuery(query, solrParams); addBoostFunctions(query, solrParams); 2. refactor the addMainQuery() method to use getUserQuery(userQuery, up, solrParams) getAlternateUserQuery(solrParams) getPhraseQuery(userQuery, pp) 3. move the DismaxQParser to the top-level to make it public (and allow subclassing) After applying this change I can to as follows: 1. write my own QParserPlugin to return a subclass of the DismaxQParser 2. in this subclass I override the the methods I need, in my case the getUserQuery() method. 3. add this plugin to the solrconfig.xml and use it the patch is done against the Solr svn trunk -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-786) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser
[ https://issues.apache.org/jira/browse/SOLR-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Biela updated SOLR-786: Attachment: (was: dismax-query-parser.patch) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser -- Key: SOLR-786 URL: https://issues.apache.org/jira/browse/SOLR-786 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3, 1.3.1, 1.4 Reporter: Wojciech Biela Priority: Minor Fix For: 1.3.1 I needed to change some of the default behaviour of the DismaxQParser, so as opposed to infecting the solr codebase with our custom behaviour, I wanted to be able to subclass the DismaxQParser and change only what we wanted to change. Here I submit a patch that allows for such subclassing. The change that is done to the code base in the following steps: 1. refactor in the DismaxQParser.parse() method to addMainQuery(query, solrParams); addBoostQuery(query, solrParams); addBoostFunctions(query, solrParams); 2. refactor the addMainQuery() method to use getUserQuery(userQuery, up, solrParams) getAlternateUserQuery(solrParams) getPhraseQuery(userQuery, pp) 3. move the DismaxQParser to the top-level to make it public (and allow subclassing) After applying this change I can to as follows: 1. write my own QParserPlugin to return a subclass of the DismaxQParser 2. in this subclass I override the the methods I need, in my case the getUserQuery() method. 3. add this plugin to the solrconfig.xml and use it the patch is done against the Solr svn trunk -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-786) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser
[ https://issues.apache.org/jira/browse/SOLR-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Biela updated SOLR-786: Attachment: dismax-query-parser.patch corrected patch (added the ASL 2.0 Licence note) refactor in DisMaxQParserPlugin and DismaxQParser to allow extending DismaxQParser -- Key: SOLR-786 URL: https://issues.apache.org/jira/browse/SOLR-786 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3, 1.3.1, 1.4 Reporter: Wojciech Biela Priority: Minor Fix For: 1.3.1 Attachments: dismax-query-parser.patch I needed to change some of the default behaviour of the DismaxQParser, so as opposed to infecting the solr codebase with our custom behaviour, I wanted to be able to subclass the DismaxQParser and change only what we wanted to change. Here I submit a patch that allows for such subclassing. The change that is done to the code base in the following steps: 1. refactor in the DismaxQParser.parse() method to addMainQuery(query, solrParams); addBoostQuery(query, solrParams); addBoostFunctions(query, solrParams); 2. refactor the addMainQuery() method to use getUserQuery(userQuery, up, solrParams) getAlternateUserQuery(solrParams) getPhraseQuery(userQuery, pp) 3. move the DismaxQParser to the top-level to make it public (and allow subclassing) After applying this change I can to as follows: 1. write my own QParserPlugin to return a subclass of the DismaxQParser 2. in this subclass I override the the methods I need, in my case the getUserQuery() method. 3. add this plugin to the solrconfig.xml and use it the patch is done against the Solr svn trunk -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-763) Support for LUCENE-1380 :: ShingleFilter.enablePositions
[ https://issues.apache.org/jira/browse/SOLR-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mck SembWever updated SOLR-763: --- Attachment: SOLR-763-PositionFilterFactory.patch Alternative patch for matching PositionFilter.java patch found in LUCENE-1380 Support for LUCENE-1380 :: ShingleFilter.enablePositions Key: SOLR-763 URL: https://issues.apache.org/jira/browse/SOLR-763 Project: Solr Issue Type: Improvement Reporter: Mck SembWever Fix For: 1.4 Attachments: SOLR-763-PositionFilterFactory.patch, SOLR-763.patch Patch so that ShingleFilterFactory can deserialise the coterminalPositionIncrement property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-781) Change facet.sort from boolean to string and specify sort method explicitely
[ https://issues.apache.org/jira/browse/SOLR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic updated SOLR-781: -- Fix Version/s: 1.4 Change facet.sort from boolean to string and specify sort method explicitely Key: SOLR-781 URL: https://issues.apache.org/jira/browse/SOLR-781 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Lars Kotthoff Assignee: Erik Hatcher Fix For: 1.4 Attachments: SOLR-781.patch The facet.sort parameter is currently a boolean, which has some downsides as explained in http://www.nabble.com/facet.sort-parameter-td19570834.html Changing it to a string which explicitely states the sort method would address these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-787) SolrJ POM refers to stax parser
SolrJ POM refers to stax parser --- Key: SOLR-787 URL: https://issues.apache.org/jira/browse/SOLR-787 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Priority: Minor Fix For: 1.3.1 Solr core moved to using woodstox instead of stax but SolrJ POM still has a dependency to stax. We should replace the dependency to stax with woodstox jar in SolrJ's POM. This is not a huge problem as we are not distributing stax anymore but is needed for consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-781) Change facet.sort from boolean to string and specify sort method explicitely
[ https://issues.apache.org/jira/browse/SOLR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633848#action_12633848 ] Hoss Man commented on SOLR-781: --- Note the comment i made in the thread after Lars opend this issue ... we need to make sure there's at least one test verifying that bool name=facet.sorttrue/bool still works if people are using it as a default/appends/invariant in their configs. also: a quick skim a the patch suggests all of the old tests were changed to use count and lex ... there should probably still be at least one or two using true and false to prove that the back-compat works. lastly: an enum would probably make sense here rather then a lot of `sort.equals(count) || sort.equals(true)}` sprinkled throughout the code. Change facet.sort from boolean to string and specify sort method explicitely Key: SOLR-781 URL: https://issues.apache.org/jira/browse/SOLR-781 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Lars Kotthoff Assignee: Erik Hatcher Fix For: 1.4 Attachments: SOLR-781.patch The facet.sort parameter is currently a boolean, which has some downsides as explained in http://www.nabble.com/facet.sort-parameter-td19570834.html Changing it to a string which explicitely states the sort method would address these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields
[
https://issues.apache.org/jira/browse/SOLR-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otis Gospodnetic updated SOLR-680:
--
Fix Version/s: 1.4
StatsComponent - get min, max, sum, qt, avg of number fields
Key: SOLR-680
URL: https://issues.apache.org/jira/browse/SOLR-680
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Koji Sekiguchi
Priority: Minor
Fix For: 1.4
Attachments: SOLR-680.patch
StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
request parameters:
stats=onstats.field=price
{code:xml}
stats
stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
/stats_fields
/stats
{code}
WRT stats, the component can output sum and avg, but not sd and var.
USE CASE:
StatsComponent can be used to get market price of DocSet e.g. rental
housing site, package tour site.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-657) Replace deprecated calls with the non-deprecated equivalents
[ https://issues.apache.org/jira/browse/SOLR-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic updated SOLR-657: -- Priority: Minor (was: Major) Fix Version/s: 1.4 Replace deprecated calls with the non-deprecated equivalents Key: SOLR-657 URL: https://issues.apache.org/jira/browse/SOLR-657 Project: Solr Issue Type: Task Affects Versions: 1.3 Reporter: Lars Kotthoff Priority: Minor Fix For: 1.4 Attachments: SOLR-657-impl-depr.patch, SOLR-657.patch, SOLR-657.patch, SOLR-657.patch, SOLR-657.patch, SOLR-657.patch There are numerous calls to deprecated constructors and methods in the code base. This includes deprecations from Solr itself, Lucene, and Java. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SolrPluginUtils.flattenBooleanQuery, dismax min-should-match
To whomever developed flattenBooleanQuery: Why is the dismax query being flattened? It would seem that because of the limited syntax that DisMaxQParserPlugin employs, all you would ever get is a one-level boolean query but I am probably missing something. ~ David -- View this message in context: http://www.nabble.com/SolrPluginUtils.flattenBooleanQuery%2C-dismax-min-should-match-tp19635127p19635127.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Setting Fix Version in JIRA
Hi, When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? If every issue had Fix Version set we'd be able to schedule things better, give reporters and others more insight into when a particular item will be taken care of, etc. When we are ready for the release we'd just bump all unresolved issues to the next planned version (e.g. Solr 1.3.1 or 1.4 or Lucene 2.4 or 2.9) Thoughts? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Re: Setting Fix Version in JIRA
When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? I think that not setting the value until it's known how big and difficult the issue is would be better. But that's just personal preference I guess. Lars
[jira] Updated: (SOLR-780) Enhance SpellCheckComponent to automatically build on firstSearcher in case of RAMDirectory based indices
[ https://issues.apache.org/jira/browse/SOLR-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-780: --- Fix Version/s: 1.4 Affects Version/s: 1.4 Enhance SpellCheckComponent to automatically build on firstSearcher in case of RAMDirectory based indices - Key: SOLR-780 URL: https://issues.apache.org/jira/browse/SOLR-780 Project: Solr Issue Type: Improvement Components: spellchecker Affects Versions: 1.4 Environment: Java Reporter: Oleg Gnatovskiy Priority: Minor Fix For: 1.4 The spellcheck compnent currently does not automatically reload when a RAMDirectory is used. Is it possible to reload a RAMDirectory spell check index using firstSearcher? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-783) DIH - Better support for handling delta-imports per entity
[
https://issues.apache.org/jira/browse/SOLR-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-783:
---
Fix Version/s: 1.4
DIH - Better support for handling delta-imports per entity
--
Key: SOLR-783
URL: https://issues.apache.org/jira/browse/SOLR-783
Project: Solr
Issue Type: Wish
Components: contrib - DataImportHandler
Affects Versions: 1.3
Environment: Linux, OpenSolaris
Reporter: Jon Baer
Priority: Minor
Fix For: 1.4
Currently there is no way to perform a delta import per entity because
${dataimporter.last_index_time} really represents the entire delta-import for
all entities and is only a single dataimport.properties file.
A delta-import w/ dataimport?command=delta-importentity=a and
dataimport?command=delta-importentity=b should result in:
${dataimporter.[name of entity].last_index_time}
${dataimporter.[name of entity].last_index_time}
I do this now because I have a single multicore representing different docs
coming from different entities.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
solr.servlet package not in 1.3 source code
runtime error when starting solr 1.3. it appears solr.servlet package is not in the source code. any idea? thanks SEVERE: Exception starting filter SolrRequestFilter java.lang.ClassNotFoundException: org.apache.solr.servlet.SolrDispatchFilter at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:207) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:78) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4222) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433) -aj -- AJ Chen, PhD Co-Chair, Semantic Web SIG, sdforum.org Technical Architect, healthline.com http://web2express.org Palo Alto, CA
Re: Setting Fix Version in JIRA
On 23-Sep-08, at 12:33 PM, Otis Gospodnetic wrote: Hi, When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? If every issue had Fix Version set we'd be able to schedule things better, give reporters and others more insight into when a particular item will be taken care of, etc. When we are ready for the release we'd just bump all unresolved issues to the next planned version (e.g. Solr 1.3.1 or 1.4 or Lucene 2.4 or 2.9) -1 I doesn't make sense to automatically schedule something to be fixed in the next version of the product. I would be +1 on automatically setting the fix version for the current unreleased version when an issue is resolved as fixed, though. -Mike
Re: Setting Fix Version in JIRA
Based on our experience with using Jira in this manner, I would agree with Mike that you do not want to automatically assign the Fix Version. Once you go down this path, you wind up with a steadily growing wave of deferred issues that are constantly getting pushed out to the next release. -- Ken When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? If every issue had Fix Version set we'd be able to schedule things better, give reporters and others more insight into when a particular item will be taken care of, etc. When we are ready for the release we'd just bump all unresolved issues to the next planned version (e.g. Solr 1.3.1 or 1.4 or Lucene 2.4 or 2.9) -1 I doesn't make sense to automatically schedule something to be fixed in the next version of the product. I would be +1 on automatically setting the fix version for the current unreleased version when an issue is resolved as fixed, though. -Mike -- Ken Krugler Krugle, Inc. +1 530-210-6378 If you can't find it, you can't fix it
