[jira] [Commented] (LUCENE-3023) Land DWPT on trunk
[
https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027428#comment-13027428
]
Michael Busch commented on LUCENE-3023:
---
Just a few minor comments, otherwise +1 to commit! (I'm super excited this is
finally happening after the branch was created a year ago or so!)
* In DocumentsWriterPerThreadPool:
remove: {code}
+ //public abstract void clearThreadBindings(ThreadState perThread);
+
+ //public abstract void clearAllThreadBindings();
+
{code}
* In ThreadAffinityDocumentsWriterThreadPool#getAndLock() we had talked about
switching from a per-threadstate queue (safeway model) to a single queue (whole
foods). I'm wondering if we should do that before we commit or change that
later as a separate patch?
* remove some commented out code in TestFlushByRamOrCountsPolicy#testHealthyness
> Land DWPT on trunk
> --
>
> Key: LUCENE-3023
> URL: https://issues.apache.org/jira/browse/LUCENE-3023
> Project: Lucene - Java
> Issue Type: Task
>Affects Versions: CSF branch, 4.0
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-3023-svn-diff.patch,
> LUCENE-3023-ws-changes.patch, LUCENE-3023.patch, LUCENE-3023.patch,
> LUCENE-3023.patch, LUCENE-3023.patch, LUCENE-3023_CHANGES.patch,
> LUCENE-3023_CHANGES.patch, LUCENE-3023_iw_iwc_jdoc.patch,
> LUCENE-3023_simonw_review.patch, LUCENE-3023_svndiff.patch,
> LUCENE-3023_svndiff.patch, diffMccand.py, diffSources.patch,
> diffSources.patch, realtime-TestAddIndexes-3.txt,
> realtime-TestAddIndexes-5.txt,
> realtime-TestIndexWriterExceptions-assert-6.txt,
> realtime-TestIndexWriterExceptions-npe-1.txt,
> realtime-TestIndexWriterExceptions-npe-2.txt,
> realtime-TestIndexWriterExceptions-npe-4.txt,
> realtime-TestOmitTf-corrupt-0.txt
>
>
> With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so
> we can proceed landing the DWPT development on trunk soon. I think one of the
> bigger issues here is to make sure that all JavaDocs for IW etc. are still
> correct though. I will start going through that first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-trunk - Build # 1547 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-trunk/1547/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestNRTThreads.testNRTThreads Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1246) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1175) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:535) Build Log (for compile errors): [...truncated 11917 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
I was accepted in GSoC!!!
Hi, That's great, I am waiting next instructions from google, it seems there is some paperwork to do. Regards, Vinicius Barros --- Em seg, 25/4/11, no-re...@socghop.appspotmail.com escreveu: De: no-re...@socghop.appspotmail.com Assunto: Congratulations! Para: viniciusbarros.g...@yahoo.com.br Data: Segunda-feira, 25 de Abril de 2011, 15:48 Dear Vinicius, Congratulations! Your proposal "LUCENE-1768: NumericRange support for new query parser" as submitted to "Apache Software Foundation" has been accepted for Google Summer of Code 2011. Over the next few days, we will add you to the private Google Summer of Code Student Discussion List. Over the next few weeks, we will send instructions to this list regarding turn in proof of enrollment, tax forms, etc. Now that you've been accepted, please take the opportunity to speak with your mentors about plans for the Community Bonding Period: what documentation should you be reading, what version control system will you need to set up, etc., before start of coding begins on May 23rd. Welcome to Google Summer of Code 2011! We look forward to having you with us. With best regards, The Google Summer of Code Program Administration Team
[jira] [Updated] (LUCENE-3058) FST should allow more than one output for the same input
[ https://issues.apache.org/jira/browse/LUCENE-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-3058: --- Attachment: LUCENE-3058.patch New patch; no change -- just more friendly for "patch" (looks like svn diff not hg diff). > FST should allow more than one output for the same input > > > Key: LUCENE-3058 > URL: https://issues.apache.org/jira/browse/LUCENE-3058 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.0 > > Attachments: LUCENE-3058.patch, LUCENE-3058.patch > > > For the block tree terms dict, it turns out I need this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027385#comment-13027385 ] Yonik Seeley commented on LUCENE-3023: -- +1! (after a not-so-thorough review ;-) > Land DWPT on trunk > -- > > Key: LUCENE-3023 > URL: https://issues.apache.org/jira/browse/LUCENE-3023 > Project: Lucene - Java > Issue Type: Task >Affects Versions: CSF branch, 4.0 >Reporter: Simon Willnauer >Assignee: Simon Willnauer > Fix For: 4.0 > > Attachments: LUCENE-3023-svn-diff.patch, > LUCENE-3023-ws-changes.patch, LUCENE-3023.patch, LUCENE-3023.patch, > LUCENE-3023.patch, LUCENE-3023.patch, LUCENE-3023_CHANGES.patch, > LUCENE-3023_CHANGES.patch, LUCENE-3023_iw_iwc_jdoc.patch, > LUCENE-3023_simonw_review.patch, LUCENE-3023_svndiff.patch, > LUCENE-3023_svndiff.patch, diffMccand.py, diffSources.patch, > diffSources.patch, realtime-TestAddIndexes-3.txt, > realtime-TestAddIndexes-5.txt, > realtime-TestIndexWriterExceptions-assert-6.txt, > realtime-TestIndexWriterExceptions-npe-1.txt, > realtime-TestIndexWriterExceptions-npe-2.txt, > realtime-TestIndexWriterExceptions-npe-4.txt, > realtime-TestOmitTf-corrupt-0.txt > > > With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so > we can proceed landing the DWPT development on trunk soon. I think one of the > bigger issues here is to make sure that all JavaDocs for IW etc. are still > correct though. I will start going through that first. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1418) QueryParser can throw NullPointerException during parsing of some queries in case if default field passed to constructor is null
[
https://issues.apache.org/jira/browse/LUCENE-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027384#comment-13027384
]
David Smiley commented on LUCENE-1418:
--
Sorry, but I disagree Mark & Shai.
The status quo (doing nothing) is the worst option. If committers decide the
default field is mandatory then the constructor should check and throw an
exception.
But I happen to believe that null is valid. In my Solr schema.xml I don't
specify a default field because there isn't a suitable default field. I use
dismax (DisjunctionMaxQuery) and list appropriate fields for user queries. That
works fine. In every case a raw lucene query exists, it's one that I write,
not users, and I explicitly name fields appropriate for what I'm doing as
applicable. The query "*:*" for the dismax q.alt param fails due to an NPE.
This issue's title is appropriate so I'm not opening a new bug, but the
reporter's description is completely off base from my scenario since I know to
balance parenthesis in my queries ;-)
> QueryParser can throw NullPointerException during parsing of some queries in
> case if default field passed to constructor is null
>
>
> Key: LUCENE-1418
> URL: https://issues.apache.org/jira/browse/LUCENE-1418
> Project: Lucene - Java
> Issue Type: Bug
> Components: QueryParser
>Affects Versions: 2.4
> Environment: CentOS 5.2 (probably any applies)
>Reporter: Alexei Dets
>Priority: Minor
>
> In case if QueryParser was constructed using "QueryParser(String f, Analyzer
> a)" constructor and f equals null then QueryParser can fail with
> NullPointerException during parsing of some queries that _does_ contain field
> name but have unbalanced parenthesis.
> Example 1:
> Query: field:(expr1) expr2)
> Result:
> java.lang.NullPointerException
> at org.apache.lucene.index.Term.(Term.java:50)
> at org.apache.lucene.index.Term.(Term.java:36)
> at
> org.apache.lucene.queryParser.QueryParser.getFieldQuery(QueryParser.java:543)
> at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1324)
> at
> org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1211)
> at
> org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1168)
> at
> org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1128)
> at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:170)
> Example2:
> Query: field:(expr1) "expr2")
> Result:
> java.lang.NullPointerException
> at org.apache.lucene.index.Term.(Term.java:50)
> at org.apache.lucene.index.Term.(Term.java:36)
> at
> org.apache.lucene.queryParser.QueryParser.getFieldQuery(QueryParser.java:543)
> at
> org.apache.lucene.queryParser.QueryParser.getFieldQuery(QueryParser.java:612)
> at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1459)
> at
> org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1211)
> at
> org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1168)
> at
> org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1128)
> at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:170)
> Workaround: pass in constructor empty string as a default field name - in
> this case QueryParser.parse method will throw ParseException (expected result
> because query string is wrong) instead of NullPointerException.
> It is not obvious to me how to fix this so I'll describe my usecase, may be
> I'm doing something completely wrong.
> Basically I have a set of per-field queries entered by user and need to
> programmatically construct (after some preprocessing) one real Lucene query
> combined from these user-entered per-field subqueries.
> To achieve this I basically do the following (simplified a bit):
> QueryParser parser = new QueryParser(null, analyzer); // I'll always provide
> a field name in a query string as it is different each time and I don't have
> any default
> BooleanQuery query = new BooleanQuery();
> Query subQuery1 = parser.parse(field1 + ":(" + queryString1 + ')');
> query.add(subQuery1, operator1); // operator = BooleanClause.Occur.MUST,
> BooleanClause.Occur.MUST_NOT or BooleanClause.Occur.SHOULD
> Query subQuery2 = parser.parse(field2 + ":(" + queryString2 + ')');
> query.add(subQuery2, operator2);
> Query subQuery3 = parser.parse(field3 + ":(" + queryString3 + ')');
> query.add(subQuery3, operator3);
> ...
> IMHO either QueryParser constructor should be changed to throw
> NullPointerException/InvalidArgumentException in case of null field passed
> (and API documentation updated) or QueryParser.parse behavi
[jira] [Updated] (LUCENE-3058) FST should allow more than one output for the same input
[ https://issues.apache.org/jira/browse/LUCENE-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-3058: --- Attachment: LUCENE-3058.patch Patch. It was a small change to Builder, to accept same input multiple times in a row. I added an optional "merge" method to Outputs, and made a new UpToTwoIntOutputs class that handles one or two ints per input. > FST should allow more than one output for the same input > > > Key: LUCENE-3058 > URL: https://issues.apache.org/jira/browse/LUCENE-3058 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.0 > > Attachments: LUCENE-3058.patch > > > For the block tree terms dict, it turns out I need this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3058) FST should allow more than one output for the same input
FST should allow more than one output for the same input Key: LUCENE-3058 URL: https://issues.apache.org/jira/browse/LUCENE-3058 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.0 For the block tree terms dict, it turns out I need this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3057) LuceneTestCase#newFSDirectoryImpl misses to set LockFactory if ctor call throws exception
[ https://issues.apache.org/jira/browse/LUCENE-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-3057: Attachment: LUCENE-3057.patch here is a patch > LuceneTestCase#newFSDirectoryImpl misses to set LockFactory if ctor call > throws exception > - > > Key: LUCENE-3057 > URL: https://issues.apache.org/jira/browse/LUCENE-3057 > Project: Lucene - Java > Issue Type: Bug > Components: Tests >Affects Versions: 4.0 >Reporter: Simon Willnauer >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3057.patch > > > selckin reported on IRC that if you run ant test -Dtestcase=TestLockFactory > -Dtestmethod=testNativeFSLockFactoryPrefix -Dtests.directory=FSDirectory the > test fails. Since FSDirectory is an abstract class it can not be instantiated > so our code falls back to FSDirector.open. yet we miss to set the given > lockFactory though. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3057) LuceneTestCase#newFSDirectoryImpl misses to set LockFactory if ctor call throws exception
LuceneTestCase#newFSDirectoryImpl misses to set LockFactory if ctor call throws exception - Key: LUCENE-3057 URL: https://issues.apache.org/jira/browse/LUCENE-3057 Project: Lucene - Java Issue Type: Bug Components: Tests Affects Versions: 4.0 Reporter: Simon Willnauer Priority: Minor Fix For: 4.0 selckin reported on IRC that if you run ant test -Dtestcase=TestLockFactory -Dtestmethod=testNativeFSLockFactoryPrefix -Dtests.directory=FSDirectory the test fails. Since FSDirectory is an abstract class it can not be instantiated so our code falls back to FSDirector.open. yet we miss to set the given lockFactory though. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-realtime_search-branch - Build # 102 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-realtime_search-branch/102/ 14 tests failed. REGRESSION: org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration Error Message: null Stack Trace: org.apache.solr.common.cloud.ZooKeeperException: at org.apache.solr.core.CoreContainer.load(CoreContainer.java:429) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:243) at org.apache.solr.cloud.CloudStateUpdateTest.setUp(CloudStateUpdateTest.java:122) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1246) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1175) Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /collections at org.apache.zookeeper.KeeperException.create(KeeperException.java:90) at org.apache.zookeeper.KeeperException.create(KeeperException.java:42) at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1243) at org.apache.solr.common.cloud.SolrZkClient.getChildren(SolrZkClient.java:198) at org.apache.solr.common.cloud.ZkStateReader.makeShardZkNodeWatches(ZkStateReader.java:184) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:418) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CloudStateUpdateTest Error Message: ERROR: SolrIndexSearcher opens=6 closes=5 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=6 closes=5 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:119) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:293) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:70) FAILED: junit.framework.TestSuite.org.apache.solr.core.AlternateDirectoryTest Error Message: org.apache.solr.common.cloud.ZooKeeperException: Stack Trace: java.lang.RuntimeException: org.apache.solr.common.cloud.ZooKeeperException: at org.apache.solr.util.TestHarness.(TestHarness.java:153) at org.apache.solr.util.TestHarness.(TestHarness.java:135) at org.apache.solr.util.TestHarness.(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:238) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:101) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:89) at org.apache.solr.core.AlternateDirectoryTest.beforeClass(AlternateDirectoryTest.java:31) Caused by: org.apache.solr.common.cloud.ZooKeeperException: at org.apache.solr.core.CoreContainer.initZooKeeper(CoreContainer.java:184) at org.apache.solr.util.TestHarness$Initializer$1.(TestHarness.java:184) at org.apache.solr.util.TestHarness$Initializer.initialize(TestHarness.java:179) at org.apache.solr.util.TestHarness.(TestHarness.java:140) Caused by: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:54700/solr within 5000 ms at org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:124) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:121) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:69) at org.apache.solr.cloud.ZkController.(ZkController.java:104) at org.apache.solr.core.CoreContainer.initZooKeeper(CoreContainer.java:165) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestSolrDeletionPolicy2 Error Message: org.apache.solr.common.cloud.ZooKeeperException: Stack Trace: java.lang.RuntimeException: org.apache.solr.common.cloud.ZooKeeperException: at org.apache.solr.util.TestHarness.(TestHarness.java:153) at org.apache.solr.util.TestHarness.(TestHarness.java:135) at org.apache.solr.util.TestHarness.(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:238) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:101) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:89) at org.apache.solr.core.TestSolrDeletionPolicy2.beforeClass(TestSolrDeletionPolicy2.java:29) Caused by: org.apache.solr.common.cloud.ZooKeeperException: at org.apache.solr.core.CoreContainer.initZooKeeper(CoreContainer.java:184) at org.apache.solr.util.TestHarness$Initializer$1.(TestHarness.java:184) at org.apache.solr.util.TestHarness$Initializer.initialize(TestHarness.java:179) at org.apache.solr.util.TestHarness.(TestHarness.java:140) Caused by: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:54700/solr within 5000 ms at org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:124) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:12
Re: Link to nightly build test reports on main Lucene site needs updating
thanks tom, I cced dev@l.a.o simon On Fri, Apr 29, 2011 at 11:14 PM, Burton-West, Tom wrote: > Hello, > > I went to look at the "Hudson nightly builds" and tried to follow the link > from the main Lucene page > http://lucene.apache.org/java/docs/developer-resources.html#Nightly > > > The links to the Clover Test Coverage Reports point to > http://hudson.zones.apache.org/hudson/view/Lucene/job/Lucene-trunk/lastSuccessfulBuild/clover/ > but apparently hudson.zones.apache.org is no longer being used. I think > the link should point to somewhere on > https://builds.apache.org/hudson/job/Lucene-trunk/. > Is this the right list to alert whoever maintains the main Lucene pages on > lucene.apache.org? > Tom > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3055) LUCENE-2372, LUCENE-2389 made it impossible to subclass core analyzers
[ https://issues.apache.org/jira/browse/LUCENE-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027361#comment-13027361 ] Earwin Burrfoot commented on LUCENE-3055: - Could anyone remind me, why the hell do we still have Analyzer.tokenStream AND reusableTokenStream rampaging around and confusing minds? We always recommend to use the latter, Robert just fixed some of the core classes to use the latter. Also, if reusableTokenStream is the only method left standing, isn't it wise to hide actual reuse somewhere in Lucene internals and turn Analyzer into plain and dumb factory interface? > LUCENE-2372, LUCENE-2389 made it impossible to subclass core analyzers > -- > > Key: LUCENE-3055 > URL: https://issues.apache.org/jira/browse/LUCENE-3055 > Project: Lucene - Java > Issue Type: Bug > Components: Analysis >Affects Versions: 3.1 >Reporter: Ian Soboroff > > LUCENE-2372 and LUCENE-2389 marked all analyzers as final. This makes > ReusableAnalyzerBase useless, and makes it impossible to subclass e.g. > StandardAnalyzer to make a small modification e.g. to tokenStream(). These > issues don't indicate a new method of doing this. The issues don't give a > reason except for design considerations, which seems a poor reason to make a > backward-incompatible change -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3023) Land DWPT on trunk
[ https://issues.apache.org/jira/browse/LUCENE-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027354#comment-13027354 ] Simon Willnauer commented on LUCENE-3023: - +1 to commit... I reviewed one more time - looks good :) > Land DWPT on trunk > -- > > Key: LUCENE-3023 > URL: https://issues.apache.org/jira/browse/LUCENE-3023 > Project: Lucene - Java > Issue Type: Task >Affects Versions: CSF branch, 4.0 >Reporter: Simon Willnauer >Assignee: Simon Willnauer > Fix For: 4.0 > > Attachments: LUCENE-3023-svn-diff.patch, > LUCENE-3023-ws-changes.patch, LUCENE-3023.patch, LUCENE-3023.patch, > LUCENE-3023.patch, LUCENE-3023.patch, LUCENE-3023_CHANGES.patch, > LUCENE-3023_CHANGES.patch, LUCENE-3023_iw_iwc_jdoc.patch, > LUCENE-3023_simonw_review.patch, LUCENE-3023_svndiff.patch, > LUCENE-3023_svndiff.patch, diffMccand.py, diffSources.patch, > diffSources.patch, realtime-TestAddIndexes-3.txt, > realtime-TestAddIndexes-5.txt, > realtime-TestIndexWriterExceptions-assert-6.txt, > realtime-TestIndexWriterExceptions-npe-1.txt, > realtime-TestIndexWriterExceptions-npe-2.txt, > realtime-TestIndexWriterExceptions-npe-4.txt, > realtime-TestOmitTf-corrupt-0.txt > > > With LUCENE-2956 we have resolved the last remaining issue for LUCENE-2324 so > we can proceed landing the DWPT development on trunk soon. I think one of the > bigger issues here is to make sure that all JavaDocs for IW etc. are still > correct though. I will start going through that first. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3056) Support Query Rewriting Caching
[ https://issues.apache.org/jira/browse/LUCENE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male updated LUCENE-3056: --- Attachment: LUCENE-3056.patch Patch implementing what I outlined. Converted BooleanQuery over to using RewriteState. > Support Query Rewriting Caching > --- > > Key: LUCENE-3056 > URL: https://issues.apache.org/jira/browse/LUCENE-3056 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Chris Male > Attachments: LUCENE-3056.patch > > > Out of LUCENE-3041, its become apparent that using a Visitor / Walker isn't > right for caching the rewrites of Querys. Although we still intend to > introduce the Query / Walker for advanced query transformations, rewriting > still serves a purpose for very specific implementation detail writing. As > such, it can be very expensive. So I think we should introduce first class > support for rewrite caching. I also feel the key is to make the caching as > transparent as possible, to reduce the strain on Query implementors. > The TermState idea gave me the idea of maybe making a RewriteState / > RewriteCache / RewriteInterceptor, which would be consulted for rewritten > Querys. It would then maintain an internal cache that it would check. If a > value wasn't found, it'd then call Query#rewrite, and cache the result. > By having this external rewrite source, people could 'pre' rewrite Querys if > they were particularly expensive but also common. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 7580 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7580/ No tests ran. Build Log (for compile errors): [...truncated 8728 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3056) Support Query Rewriting Caching
Support Query Rewriting Caching --- Key: LUCENE-3056 URL: https://issues.apache.org/jira/browse/LUCENE-3056 Project: Lucene - Java Issue Type: Improvement Reporter: Chris Male Out of LUCENE-3041, its become apparent that using a Visitor / Walker isn't right for caching the rewrites of Querys. Although we still intend to introduce the Query / Walker for advanced query transformations, rewriting still serves a purpose for very specific implementation detail writing. As such, it can be very expensive. So I think we should introduce first class support for rewrite caching. I also feel the key is to make the caching as transparent as possible, to reduce the strain on Query implementors. The TermState idea gave me the idea of maybe making a RewriteState / RewriteCache / RewriteInterceptor, which would be consulted for rewritten Querys. It would then maintain an internal cache that it would check. If a value wasn't found, it'd then call Query#rewrite, and cache the result. By having this external rewrite source, people could 'pre' rewrite Querys if they were particularly expensive but also common. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2399) Solr Admin Interface, reworked
[ https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027307#comment-13027307 ] Stefan Matheis (steffkes) commented on SOLR-2399: - Upayavira, yes that's right .. i'm developing on Win7 with FF3. The Interface should work in Chrome, maybe also in Safari / Opera. Bugfixing -- especially for IE -- will come later > Solr Admin Interface, reworked > -- > > Key: SOLR-2399 > URL: https://issues.apache.org/jira/browse/SOLR-2399 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.0 > > > *The idea was to create a new, fresh (and hopefully clean) Solr Admin > Interface.* [Based on this > [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] > I've quickly created a Github-Repository (Just for me, to keep track of the > changes) > » https://github.com/steffkes/solr-admin > Quick Tour: [Dashboard|http://files.mathe.is/solr-admin/01_dashboard.png], > [Query-Form|http://files.mathe.is/solr-admin/02_query.png], > [Plugins|http://files.mathe.is/solr-admin/05_plugins.png], > [Logging|http://files.mathe.is/solr-admin/07_logging.png], > [Analysis|http://files.mathe.is/solr-admin/04_analysis.png], > [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png], > [Dataimport|http://files.mathe.is/solr-admin/08_dataimport.png] > Newly created Wiki-Page: http://wiki.apache.org/solr/ReworkedSolrAdminGUI -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2399) Solr Admin Interface, reworked
[ https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027306#comment-13027306 ] Stefan Matheis (steffkes) commented on SOLR-2399: - So, made a bit progress on another Topic -- [the Dataimport Screen|http://files.mathe.is/solr-admin/08_dataimport.png]. The Ideas behind: * Make it clear, that the config could not be edited in this screen. So by default it's hidden, could be toggled and has Syntax-Highlighting (as seen in the screen) * Update the (Progress-)Status in Screen, while a Import is Running (actually, the interval is 2s) > Solr Admin Interface, reworked > -- > > Key: SOLR-2399 > URL: https://issues.apache.org/jira/browse/SOLR-2399 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.0 > > > *The idea was to create a new, fresh (and hopefully clean) Solr Admin > Interface.* [Based on this > [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] > I've quickly created a Github-Repository (Just for me, to keep track of the > changes) > » https://github.com/steffkes/solr-admin > Quick Tour: [Dashboard|http://files.mathe.is/solr-admin/01_dashboard.png], > [Query-Form|http://files.mathe.is/solr-admin/02_query.png], > [Plugins|http://files.mathe.is/solr-admin/05_plugins.png], > [Logging|http://files.mathe.is/solr-admin/07_logging.png], > [Analysis|http://files.mathe.is/solr-admin/04_analysis.png], > [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png] > Newly created Wiki-Page: http://wiki.apache.org/solr/ReworkedSolrAdminGUI -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2399) Solr Admin Interface, reworked
[ https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-2399: Description: *The idea was to create a new, fresh (and hopefully clean) Solr Admin Interface.* [Based on this [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] I've quickly created a Github-Repository (Just for me, to keep track of the changes) » https://github.com/steffkes/solr-admin Quick Tour: [Dashboard|http://files.mathe.is/solr-admin/01_dashboard.png], [Query-Form|http://files.mathe.is/solr-admin/02_query.png], [Plugins|http://files.mathe.is/solr-admin/05_plugins.png], [Logging|http://files.mathe.is/solr-admin/07_logging.png], [Analysis|http://files.mathe.is/solr-admin/04_analysis.png], [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png], [Dataimport|http://files.mathe.is/solr-admin/08_dataimport.png] Newly created Wiki-Page: http://wiki.apache.org/solr/ReworkedSolrAdminGUI was: *The idea was to create a new, fresh (and hopefully clean) Solr Admin Interface.* [Based on this [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] I've quickly created a Github-Repository (Just for me, to keep track of the changes) » https://github.com/steffkes/solr-admin Quick Tour: [Dashboard|http://files.mathe.is/solr-admin/01_dashboard.png], [Query-Form|http://files.mathe.is/solr-admin/02_query.png], [Plugins|http://files.mathe.is/solr-admin/05_plugins.png], [Logging|http://files.mathe.is/solr-admin/07_logging.png], [Analysis|http://files.mathe.is/solr-admin/04_analysis.png], [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png] Newly created Wiki-Page: http://wiki.apache.org/solr/ReworkedSolrAdminGUI > Solr Admin Interface, reworked > -- > > Key: SOLR-2399 > URL: https://issues.apache.org/jira/browse/SOLR-2399 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.0 > > > *The idea was to create a new, fresh (and hopefully clean) Solr Admin > Interface.* [Based on this > [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] > I've quickly created a Github-Repository (Just for me, to keep track of the > changes) > » https://github.com/steffkes/solr-admin > Quick Tour: [Dashboard|http://files.mathe.is/solr-admin/01_dashboard.png], > [Query-Form|http://files.mathe.is/solr-admin/02_query.png], > [Plugins|http://files.mathe.is/solr-admin/05_plugins.png], > [Logging|http://files.mathe.is/solr-admin/07_logging.png], > [Analysis|http://files.mathe.is/solr-admin/04_analysis.png], > [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png], > [Dataimport|http://files.mathe.is/solr-admin/08_dataimport.png] > Newly created Wiki-Page: http://wiki.apache.org/solr/ReworkedSolrAdminGUI -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3041) Support Query Visting / Walking
[
https://issues.apache.org/jira/browse/LUCENE-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated LUCENE-3041:
---
Attachment: LUCENE-3041.patch
New patch that implements what I said in the previous comments (except for the
IS changes).
Also a test is now included.
> Support Query Visting / Walking
> ---
>
> Key: LUCENE-3041
> URL: https://issues.apache.org/jira/browse/LUCENE-3041
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
>Reporter: Chris Male
>Priority: Minor
> Attachments: LUCENE-3041.patch, LUCENE-3041.patch, LUCENE-3041.patch,
> LUCENE-3041.patch, LUCENE-3041.patch
>
>
> Out of the discussion in LUCENE-2868, it could be useful to add a generic
> Query Visitor / Walker that could be used for more advanced rewriting,
> optimizations or anything that requires state to be stored as each Query is
> visited.
> We could keep the interface very simple:
> {code}
> public interface QueryVisitor {
> Query visit(Query query);
> }
> {code}
> and then use a reflection based visitor like Earwin suggested, which would
> allow implementators to provide visit methods for just Querys that they are
> interested in.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
