[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767225#action_12767225 ] Uwe Schindler commented on LUCENE-1257: --- bq. I did not touch StopFilter or StopAnalyzer due to some mixed CharArraySet / Set usage... any ideas on this one Uwe? I am hanging on that, too. See also LUCENE-1987 and LUCENE-1989. As this set needs no type safety (when it is implemented by CharArraySet) it does not matter if the contains methods uses char[] or String or even Object. It always compares the string representation of the tested value. As CharArraySet is defined as Set, we should define all these as Set in StopFilter. Or declare them as CharArraySet and convert the anonyous Set to CharArraySet in the ctor (I would prefer this). > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CloseableThreadLocal.patch, > LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_analysis.patch, LUCENE-1257_BooleanFilter_Generics.patch, > LUCENE-1257_messages.patch, LUCENE-1257_o.a.l.queryParser.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1992) intermittent failure in TestIndexWriter. testExceptionDuringSync
[
https://issues.apache.org/jira/browse/LUCENE-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767223#action_12767223
]
Uwe Schindler commented on LUCENE-1992:
---
>From the patch:
{code}
-// We expect sync exceptions in the merge threads
-cms.setSuppressExceptions();
{code}
Should this also applied to bw branch (2.4 for) 2.9 and (2.9 for) 3.0? I do not
know what this call really does and what effect it has.
> intermittent failure in TestIndexWriter. testExceptionDuringSync
> -
>
> Key: LUCENE-1992
> URL: https://issues.apache.org/jira/browse/LUCENE-1992
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.9.1, 3.0
>
> Attachments: LUCENE-1992.patch
>
>
> {code}
> common.test:
> [mkdir] Created dir: C:\Projects\lucene\trunk-full1\build\test
> [junit] Testsuite: org.apache.lucene.index.TestIndexWriter
> [junit] Tests run: 102, Failures: 0, Errors: 1, Time elapsed: 100,297sec
> [junit]
> [junit] Testcase:
> testExceptionDuringSync(org.apache.lucene.index.TestIndexWriter): Caused an
> ERROR
> [junit] _a.fnm
> [junit] java.io.FileNotFoundException: _a.fnm
> [junit] at
> org.apache.lucene.store.MockRAMDirectory.openInput(MockRAMDirectory.java:226)
> [junit] at
> org.apache.lucene.index.FieldInfos.(FieldInfos.java:68)
> [junit] at
> org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:116)
> [junit] at
> org.apache.lucene.index.SegmentReader.get(SegmentReader.java:620)
> [junit] at
> org.apache.lucene.index.SegmentReader.get(SegmentReader.java:590)
> [junit] at
> org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:104)
> [junit] at
> org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryReader.java:27)
> [junit] at
> org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74)
> [junit] at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704)
> [junit] at
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69)
> [junit] at
> org.apache.lucene.index.IndexReader.open(IndexReader.java:307)
> [junit] at
> org.apache.lucene.index.IndexReader.open(IndexReader.java:193)
> [junit] at
> org.apache.lucene.index.TestIndexWriter.testExceptionDuringSync(TestIndexWriter.java:2723)
> [junit] at
> org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:206)
> [junit]
> [junit]
> [junit] Test org.apache.lucene.index.TestIndexWriter FAILED
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Call the authorities
Mark Miller wrote: > TestStressSort has been butchered. > > I suppose we could just pull it since it wouldn't check for much any more - looks awful funny as is. -- - Mark http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Call the authorities
TestStressSort has been butchered. -- - Mark http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257-CloseableThreadLocal.patch Classes affected: * TermInfosReader * SegmentReader * FieldsReader > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CloseableThreadLocal.patch, > LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_analysis.patch, LUCENE-1257_BooleanFilter_Generics.patch, > LUCENE-1257_messages.patch, LUCENE-1257_o.a.l.queryParser.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-1257: Attachment: LUCENE-1257_analysis.patch updated analysis patch. I did not touch StopFilter or StopAnalyzer due to some mixed CharArraySet / Set usage... any ideas on this one Uwe? > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_analysis.patch, LUCENE-1257_BooleanFilter_Generics.patch, > LUCENE-1257_messages.patch, LUCENE-1257_o.a.l.queryParser.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1945) Make all classes that have a close() methods instanceof Closeable (Java 1.5)
[ https://issues.apache.org/jira/browse/LUCENE-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767165#action_12767165 ] Earwin Burrfoot commented on LUCENE-1945: - Package-private classes might as well implement public close(), nobody's gonna see this method from outside anyway. > Make all classes that have a close() methods instanceof Closeable (Java 1.5) > > > Key: LUCENE-1945 > URL: https://issues.apache.org/jira/browse/LUCENE-1945 > Project: Lucene - Java > Issue Type: Improvement >Affects Versions: 2.9 >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Trivial > Fix For: 3.0 > > Attachments: LUCENE-1945.patch > > > This should be simple. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Resolved: (LUCENE-1992) intermittent failure in TestIndexWriter. testExceptionDuringSync
[
https://issues.apache.org/jira/browse/LUCENE-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1992.
Resolution: Fixed
Fix Version/s: 2.9.1
Thanks for reporting this Uwe!
> intermittent failure in TestIndexWriter. testExceptionDuringSync
> -
>
> Key: LUCENE-1992
> URL: https://issues.apache.org/jira/browse/LUCENE-1992
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.9.1, 3.0
>
> Attachments: LUCENE-1992.patch
>
>
> {code}
> common.test:
> [mkdir] Created dir: C:\Projects\lucene\trunk-full1\build\test
> [junit] Testsuite: org.apache.lucene.index.TestIndexWriter
> [junit] Tests run: 102, Failures: 0, Errors: 1, Time elapsed: 100,297sec
> [junit]
> [junit] Testcase:
> testExceptionDuringSync(org.apache.lucene.index.TestIndexWriter): Caused an
> ERROR
> [junit] _a.fnm
> [junit] java.io.FileNotFoundException: _a.fnm
> [junit] at
> org.apache.lucene.store.MockRAMDirectory.openInput(MockRAMDirectory.java:226)
> [junit] at
> org.apache.lucene.index.FieldInfos.(FieldInfos.java:68)
> [junit] at
> org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:116)
> [junit] at
> org.apache.lucene.index.SegmentReader.get(SegmentReader.java:620)
> [junit] at
> org.apache.lucene.index.SegmentReader.get(SegmentReader.java:590)
> [junit] at
> org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:104)
> [junit] at
> org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryReader.java:27)
> [junit] at
> org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74)
> [junit] at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704)
> [junit] at
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69)
> [junit] at
> org.apache.lucene.index.IndexReader.open(IndexReader.java:307)
> [junit] at
> org.apache.lucene.index.IndexReader.open(IndexReader.java:193)
> [junit] at
> org.apache.lucene.index.TestIndexWriter.testExceptionDuringSync(TestIndexWriter.java:2723)
> [junit] at
> org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:206)
> [junit]
> [junit]
> [junit] Test org.apache.lucene.index.TestIndexWriter FAILED
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1992) intermittent failure in TestIndexWriter. testExceptionDuringSync
[
https://issues.apache.org/jira/browse/LUCENE-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1992:
---
Attachment: LUCENE-1992.patch
Patch attached. I'll commit shortly on trunk & 2.9.1.
There is a thread hazard that happens when a merge is committing just
as an exception is happening during sync. There merge actually
changes the segmentInfos, but fails to checkpoint before exiting the
sync block. If an exception during syncing is handled in another
thread, this can then decRef the newly merged segment to 0, deleting
it too early.
> intermittent failure in TestIndexWriter. testExceptionDuringSync
> -
>
> Key: LUCENE-1992
> URL: https://issues.apache.org/jira/browse/LUCENE-1992
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 3.0
>
> Attachments: LUCENE-1992.patch
>
>
> {code}
> common.test:
> [mkdir] Created dir: C:\Projects\lucene\trunk-full1\build\test
> [junit] Testsuite: org.apache.lucene.index.TestIndexWriter
> [junit] Tests run: 102, Failures: 0, Errors: 1, Time elapsed: 100,297sec
> [junit]
> [junit] Testcase:
> testExceptionDuringSync(org.apache.lucene.index.TestIndexWriter): Caused an
> ERROR
> [junit] _a.fnm
> [junit] java.io.FileNotFoundException: _a.fnm
> [junit] at
> org.apache.lucene.store.MockRAMDirectory.openInput(MockRAMDirectory.java:226)
> [junit] at
> org.apache.lucene.index.FieldInfos.(FieldInfos.java:68)
> [junit] at
> org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:116)
> [junit] at
> org.apache.lucene.index.SegmentReader.get(SegmentReader.java:620)
> [junit] at
> org.apache.lucene.index.SegmentReader.get(SegmentReader.java:590)
> [junit] at
> org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:104)
> [junit] at
> org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryReader.java:27)
> [junit] at
> org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74)
> [junit] at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704)
> [junit] at
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69)
> [junit] at
> org.apache.lucene.index.IndexReader.open(IndexReader.java:307)
> [junit] at
> org.apache.lucene.index.IndexReader.open(IndexReader.java:193)
> [junit] at
> org.apache.lucene.index.TestIndexWriter.testExceptionDuringSync(TestIndexWriter.java:2723)
> [junit] at
> org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:206)
> [junit]
> [junit]
> [junit] Test org.apache.lucene.index.TestIndexWriter FAILED
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767160#action_12767160 ] Uwe Schindler commented on LUCENE-1257: --- So we just generify the ThreadLocal to or and finito. I had that in mind. As noted before: the generic type param Kay Kay added has nothing to do with the Analyzer itsself, only with its internal impl. So do not make it public! The Object returning save/get method is just a very special helper. And this down-cast is not "unsafe" as long as you do not reuse the method from somewhere outside of Analyzer. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767158#action_12767158 ] Robert Muir commented on LUCENE-1257: - Uwe, I agree. I think if we want to improve this reusability in the future, we should look at doing something similar to what Shai Erera proposed, a subclass of Analyzer that does the common SavedStreams behavior. But I think Analyzer should still have Object, so the special cases like QueryAutoStopWord can be implemented. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767157#action_12767157 ] Uwe Schindler commented on LUCENE-1257: --- Robert: Thanks! But we should not generify the wole analyzer class just because we have some internal helper API that may be generified. We are OK with casts from Object downto the actual type here. A type param in Analyzer is strange and confusing for outstanding developers. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767155#action_12767155
]
Uwe Schindler commented on LUCENE-1257:
---
{quote}
bq. LUCENE-1257_o.a.l.queryParser.patch
This is hard to generify, because parts of the API are provided by javacc. You
can only patch the .jj file but only parts not automatically generated by
javacc.
I would keep this classes as they are and maybe update javacc's param to
generate 1.5 code. I will look into this.
{quote}
I updated the parser generator task to use Java 1.5. If you want to generify
the other parts of QueryParser, update the .jj file and regenerate the java
files. I will do this tomorrow. Will go to bed now.
> Port to Java5
> -
>
> Key: LUCENE-1257
> URL: https://issues.apache.org/jira/browse/LUCENE-1257
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis, Examples, Index, Other, Query/Scoring,
> QueryParser, Search, Store, Term Vectors
>Affects Versions: 3.0
>Reporter: Cédric Champeau
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 3.0
>
> Attachments: instantiated_fieldable.patch, java5.patch,
> LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch,
> LUCENE-1257-BufferedDeletes_DocumentsWriter.patch,
> LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch,
> LUCENE-1257-ConcurrentMergeScheduler.patch,
> LUCENE-1257-DirectoryReader.patch,
> LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch,
> LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch,
> LUCENE-1257-IndexDeleter.patch,
> LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch,
> LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch,
> LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch,
> LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch,
> LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch,
> LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch,
> LUCENE-1257_org_apache_lucene_index.patch,
> LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch,
> lucene1257surround1.patch, o.a.l.analysis.patch,
> shinglematrixfilter_generified.patch
>
>
> For my needs I've updated Lucene so that it uses Java 5 constructs. I know
> Java 5 migration had been planned for 2.1 someday in the past, but don't know
> when it is planned now. This patch against the trunk includes :
> - most obvious generics usage (there are tons of usages of sets, ... Those
> which are commonly used have been generified)
> - PriorityQueue generification
> - replacement of indexed for loops with for each constructs
> - removal of unnececessary unboxing
> The code is to my opinion much more readable with those features (you
> actually *know* what is stored in collections reading the code, without the
> need to lookup for field definitions everytime) and it simplifies many
> algorithms.
> Note that this patch also includes an interface for the Query class. This has
> been done for my company's needs for building custom Query classes which add
> some behaviour to the base Lucene queries. It prevents multiple unnnecessary
> casts. I know this introduction is not wanted by the team, but it really
> makes our developments easier to maintain. If you don't want to use this,
> replace all /Queriable/ calls with standard /Query/.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767156#action_12767156
]
Robert Muir commented on LUCENE-1257:
-
{quote}
>From your patch, it seems that you want to generify the setPreviousTokenStream
>method. This shoudl not take Object, it should take TokenStream as param. But
>this has nothing to do with Java 5.
{quote}
check out LUCENE-1794 for some related discussion.
There are a few things that come to mind:
* for reusable token streams, an analyzer needs to reset the chain: .reset(),
but it also needs to call reset(Reader) which is only applicable to Tokenizer.
This is why you see private classes like SavedStreams being used.
* because .tokenStream() takes a fieldname as an argument, some analyzers have
special field-specific behavior. To reuse for these analyzers can be more
complex, for example QueryAutoStopWordAnalyzer sets/gets a map.
> Port to Java5
> -
>
> Key: LUCENE-1257
> URL: https://issues.apache.org/jira/browse/LUCENE-1257
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis, Examples, Index, Other, Query/Scoring,
> QueryParser, Search, Store, Term Vectors
>Affects Versions: 3.0
>Reporter: Cédric Champeau
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 3.0
>
> Attachments: instantiated_fieldable.patch, java5.patch,
> LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch,
> LUCENE-1257-BufferedDeletes_DocumentsWriter.patch,
> LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch,
> LUCENE-1257-ConcurrentMergeScheduler.patch,
> LUCENE-1257-DirectoryReader.patch,
> LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch,
> LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch,
> LUCENE-1257-IndexDeleter.patch,
> LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch,
> LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch,
> LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch,
> LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch,
> LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch,
> LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch,
> LUCENE-1257_org_apache_lucene_index.patch,
> LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch,
> lucene1257surround1.patch, o.a.l.analysis.patch,
> shinglematrixfilter_generified.patch
>
>
> For my needs I've updated Lucene so that it uses Java 5 constructs. I know
> Java 5 migration had been planned for 2.1 someday in the past, but don't know
> when it is planned now. This patch against the trunk includes :
> - most obvious generics usage (there are tons of usages of sets, ... Those
> which are commonly used have been generified)
> - PriorityQueue generification
> - replacement of indexed for loops with for each constructs
> - removal of unnececessary unboxing
> The code is to my opinion much more readable with those features (you
> actually *know* what is stored in collections reading the code, without the
> need to lookup for field definitions everytime) and it simplifies many
> algorithms.
> Note that this patch also includes an interface for the Query class. This has
> been done for my company's needs for building custom Query classes which add
> some behaviour to the base Lucene queries. It prevents multiple unnnecessary
> casts. I know this introduction is not wanted by the team, but it really
> makes our developments easier to maintain. If you don't want to use this,
> replace all /Queriable/ calls with standard /Query/.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767152#action_12767152 ] Uwe Schindler commented on LUCENE-1257: --- bq. LUCENE-1257_o.a.l.queryParser.patch This is hard to generify, because parts of the API are provided by javacc. You can only patch the .jj file but only parts not automatically generated by javacc. I would keep this classes as they are and maybe update javacc's param to generate 1.5 code. I will look into this. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767149#action_12767149 ] Uwe Schindler edited comment on LUCENE-1257 at 10/18/09 3:31 PM: - bq. First cut version of the patch. If Analyzer is ok - then other analyzers can be ported soon to this as well. That's unneeded. Analyzer always return a TokenStream and Tokenizer is a subclass of TokenStream. This makes no sense. >From your patch, it seems that you want to generify the setPreviousTokenStream >method. This shoudl not take Object, it should take TokenStream as param. But >this has nothing to do with Java 5. Robert Muir knows more, he implemented this caching. was (Author: thetaphi): bq. First cut version of the patch. If Analyzer is ok - then other analyzers can be ported soon to this as well. That's unneeded. Analyzer always return a TokenStream and Tokenizer is a subclass of TokenStream. This makes no sense. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767149#action_12767149 ] Uwe Schindler commented on LUCENE-1257: --- bq. First cut version of the patch. If Analyzer is ok - then other analyzers can be ported soon to this as well. That's unneeded. Analyzer always return a TokenStream and Tokenizer is a subclass of TokenStream. This makes no sense. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Resolved: (LUCENE-1945) Make all classes that have a close() methods instanceof Closeable (Java 1.5)
[ https://issues.apache.org/jira/browse/LUCENE-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-1945. --- Resolution: Fixed Assignee: Uwe Schindler Committed revision: 826540 > Make all classes that have a close() methods instanceof Closeable (Java 1.5) > > > Key: LUCENE-1945 > URL: https://issues.apache.org/jira/browse/LUCENE-1945 > Project: Lucene - Java > Issue Type: Improvement >Affects Versions: 2.9 >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Trivial > Fix For: 3.0 > > Attachments: LUCENE-1945.patch > > > This should be simple. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: o.a.l.analysis.patch Analyzer (generified ) Other Analyzers. First cut version of the patch. If Analyzer is ok - then other analyzers can be ported soon to this as well. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, o.a.l.analysis.patch, > shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1945) Make all classes that have a close() methods instanceof Closeable (Java 1.5)
[ https://issues.apache.org/jira/browse/LUCENE-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1945: -- Attachment: LUCENE-1945.patch Patch that adds Closeable to all public interfaces/super-classes that define close(). Package-private classes inside oal.index are not changed (as they often only define package-private close()) Will commit soon. > Make all classes that have a close() methods instanceof Closeable (Java 1.5) > > > Key: LUCENE-1945 > URL: https://issues.apache.org/jira/browse/LUCENE-1945 > Project: Lucene - Java > Issue Type: Improvement >Affects Versions: 2.9 >Reporter: Uwe Schindler >Priority: Trivial > Fix For: 3.0 > > Attachments: LUCENE-1945.patch > > > This should be simple. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257_o.a.l.queryParser.patch o.a.l.queryParser > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767140#action_12767140 ] Uwe Schindler commented on LUCENE-1257: --- bq. IndexFileDeleter, IndexDeletePolicy Last patch makes sense, its better to use abstract base class! Committed. With generified ThreadLocal I get now 73 warnings, some more :( > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Strange Test failure every 10 TestIndexWriter test runs or so
Thanks! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Michael McCandless [mailto:luc...@mikemccandless.com] > Sent: Sunday, October 18, 2009 11:48 PM > To: java-dev@lucene.apache.org > Subject: Re: Strange Test failure every 10 TestIndexWriter test runs or so > > I'll hunt it down!! > > Mike > > On Sun, Oct 18, 2009 at 5:23 PM, Uwe Schindler wrote: > > I get often the following test failure with exactly the same position > and > > file name, but only under windows, never in Solaris: > > > > > > > > common.test: > > > > [mkdir] Created dir: C:\Projects\lucene\trunk-full1\build\test > > > > [junit] Testsuite: org.apache.lucene.index.TestIndexWriter > > > > [junit] Tests run: 102, Failures: 0, Errors: 1, Time elapsed: > 100,297sec > > > > [junit] > > > > [junit] Testcase: > > testExceptionDuringSync(org.apache.lucene.index.TestIndexWriter): Caused > an > > ERROR > > > > [junit] _a.fnm > > > > [junit] java.io.FileNotFoundException: _a.fnm > > > > [junit] at > > > org.apache.lucene.store.MockRAMDirectory.openInput(MockRAMDirectory.java:2 > 26) > > > > [junit] at > > org.apache.lucene.index.FieldInfos.(FieldInfos.java:68) > > > > [junit] at > > > org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.jav > a:116) > > > > [junit] at > > org.apache.lucene.index.SegmentReader.get(SegmentReader.java:620) > > > > [junit] at > > org.apache.lucene.index.SegmentReader.get(SegmentReader.java:590) > > > > [junit] at > > org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:104) > > > > [junit] at > > > org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryRe > ader.java:27) > > > > [junit] at > > > org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74) > > > > [junit] at > > > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.jav > a:704) > > > > [junit] at > > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69) > > > > [junit] at > > org.apache.lucene.index.IndexReader.open(IndexReader.java:307) > > > > [junit] at > > org.apache.lucene.index.IndexReader.open(IndexReader.java:193) > > > > [junit] at > > > org.apache.lucene.index.TestIndexWriter.testExceptionDuringSync(TestIndexW > riter.java:2723) > > > > [junit] at > > org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:206) > > > > [junit] > > > > [junit] > > > > [junit] Test org.apache.lucene.index.TestIndexWriter FAILED > > > > > > > > Maybe it has something to do with the deprecation removal, but it also > > appeared in the past, but more seldom. > > > > > > > > Any opinion? > > > > > > > > Uwe > > > > > > > > - > > > > Uwe Schindler > > > > H.-H.-Meier-Allee 63, D-28213 Bremen > > > > http://www.thetaphi.de > > > > eMail: u...@thetaphi.de > > > > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Created: (LUCENE-1992) intermittent failure in TestIndexWriter. testExceptionDuringSync
intermittent failure in TestIndexWriter. testExceptionDuringSync
-
Key: LUCENE-1992
URL: https://issues.apache.org/jira/browse/LUCENE-1992
Project: Lucene - Java
Issue Type: Bug
Components: Index
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor
Fix For: 3.0
{code}
common.test:
[mkdir] Created dir: C:\Projects\lucene\trunk-full1\build\test
[junit] Testsuite: org.apache.lucene.index.TestIndexWriter
[junit] Tests run: 102, Failures: 0, Errors: 1, Time elapsed: 100,297sec
[junit]
[junit] Testcase:
testExceptionDuringSync(org.apache.lucene.index.TestIndexWriter): Caused an
ERROR
[junit] _a.fnm
[junit] java.io.FileNotFoundException: _a.fnm
[junit] at
org.apache.lucene.store.MockRAMDirectory.openInput(MockRAMDirectory.java:226)
[junit] at org.apache.lucene.index.FieldInfos.(FieldInfos.java:68)
[junit] at
org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:116)
[junit] at
org.apache.lucene.index.SegmentReader.get(SegmentReader.java:620)
[junit] at
org.apache.lucene.index.SegmentReader.get(SegmentReader.java:590)
[junit] at
org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:104)
[junit] at
org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryReader.java:27)
[junit] at
org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74)
[junit] at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704)
[junit] at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:307)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:193)
[junit] at
org.apache.lucene.index.TestIndexWriter.testExceptionDuringSync(TestIndexWriter.java:2723)
[junit] at
org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:206)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestIndexWriter FAILED
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Strange Test failure every 10 TestIndexWriter test runs or so
I'll hunt it down!! Mike On Sun, Oct 18, 2009 at 5:23 PM, Uwe Schindler wrote: > I get often the following test failure with exactly the same position and > file name, but only under windows, never in Solaris: > > > > common.test: > > [mkdir] Created dir: C:\Projects\lucene\trunk-full1\build\test > > [junit] Testsuite: org.apache.lucene.index.TestIndexWriter > > [junit] Tests run: 102, Failures: 0, Errors: 1, Time elapsed: 100,297sec > > [junit] > > [junit] Testcase: > testExceptionDuringSync(org.apache.lucene.index.TestIndexWriter): Caused an > ERROR > > [junit] _a.fnm > > [junit] java.io.FileNotFoundException: _a.fnm > > [junit] at > org.apache.lucene.store.MockRAMDirectory.openInput(MockRAMDirectory.java:226) > > [junit] at > org.apache.lucene.index.FieldInfos.(FieldInfos.java:68) > > [junit] at > org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java:116) > > [junit] at > org.apache.lucene.index.SegmentReader.get(SegmentReader.java:620) > > [junit] at > org.apache.lucene.index.SegmentReader.get(SegmentReader.java:590) > > [junit] at > org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:104) > > [junit] at > org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryReader.java:27) > > [junit] at > org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74) > > [junit] at > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704) > > [junit] at > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69) > > [junit] at > org.apache.lucene.index.IndexReader.open(IndexReader.java:307) > > [junit] at > org.apache.lucene.index.IndexReader.open(IndexReader.java:193) > > [junit] at > org.apache.lucene.index.TestIndexWriter.testExceptionDuringSync(TestIndexWriter.java:2723) > > [junit] at > org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:206) > > [junit] > > [junit] > > [junit] Test org.apache.lucene.index.TestIndexWriter FAILED > > > > Maybe it has something to do with the deprecation removal, but it also > appeared in the past, but more seldom. > > > > Any opinion? > > > > Uwe > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767138#action_12767138
]
Kay Kay commented on LUCENE-1257:
-
{quote} I think test code rewrite is not so important now. I think first I have
to remove the rest of the deprecations and fix the test bug (see java-dev mail).
I ran the compilation with unchecked warnings turned on, only 38 warnings for
core. I think the rest in core should be doable now JUHU!
{quote}
Ok - Makes sense. It would be nice to get it down to 0 soon..
> Port to Java5
> -
>
> Key: LUCENE-1257
> URL: https://issues.apache.org/jira/browse/LUCENE-1257
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis, Examples, Index, Other, Query/Scoring,
> QueryParser, Search, Store, Term Vectors
>Affects Versions: 3.0
>Reporter: Cédric Champeau
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 3.0
>
> Attachments: instantiated_fieldable.patch, java5.patch,
> LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch,
> LUCENE-1257-BufferedDeletes_DocumentsWriter.patch,
> LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch,
> LUCENE-1257-ConcurrentMergeScheduler.patch,
> LUCENE-1257-DirectoryReader.patch,
> LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch,
> LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch,
> LUCENE-1257-IndexDeleter.patch,
> LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch,
> LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch,
> LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch,
> LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch,
> LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch,
> LUCENE-1257_o_a_l_search_spans.patch,
> LUCENE-1257_org_apache_lucene_index.patch,
> LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch,
> lucene1257surround1.patch, shinglematrixfilter_generified.patch
>
>
> For my needs I've updated Lucene so that it uses Java 5 constructs. I know
> Java 5 migration had been planned for 2.1 someday in the past, but don't know
> when it is planned now. This patch against the trunk includes :
> - most obvious generics usage (there are tons of usages of sets, ... Those
> which are commonly used have been generified)
> - PriorityQueue generification
> - replacement of indexed for loops with for each constructs
> - removal of unnececessary unboxing
> The code is to my opinion much more readable with those features (you
> actually *know* what is stored in collections reading the code, without the
> need to lookup for field definitions everytime) and it simplifies many
> algorithms.
> Note that this patch also includes an interface for the Query class. This has
> been done for my company's needs for building custom Query classes which add
> some behaviour to the base Lucene queries. It prevents multiple unnnecessary
> casts. I know this introduction is not wanted by the team, but it really
> makes our developments easier to maintain. If you don't want to use this,
> replace all /Queriable/ calls with standard /Query/.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch IndexFileDeleter IndexDeletePolicy > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767136#action_12767136 ] Uwe Schindler commented on LUCENE-1257: --- I think test code rewrite is not so important now. I think first I have to remove the rest of the deprecations and fix the test bug (see java-dev mail). I ran the compilation with unchecked warnings turned on, only 38 warnings for core. I think the rest in core should be doable now :-) JUHU! > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, > LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Assigned: (LUCENE-1991) Similarity#score deprecated method - javadoc reference + SimilarityDelegator
[ https://issues.apache.org/jira/browse/LUCENE-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-1991: - Assignee: Uwe Schindler > Similarity#score deprecated method - javadoc reference + SimilarityDelegator > > > Key: LUCENE-1991 > URL: https://issues.apache.org/jira/browse/LUCENE-1991 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Kay Kay >Assignee: Uwe Schindler > Attachments: LUCENE-1991.patch > > > Old method > public float scorePayload(String fieldName, byte [] payload, int offset, > int length) > has been deprecated by - > public float scorePayload(int docId, String fieldName, int start, int end, > byte [] payload, int offset, int length) > References in PayLoadNearQuery (javadoc) changed. > Also - SimilarityDelegator overrides the new method as opposed to the > (deprecated) old one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1991) Similarity#score deprecated method - javadoc reference + SimilarityDelegator
[ https://issues.apache.org/jira/browse/LUCENE-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767134#action_12767134 ] Uwe Schindler commented on LUCENE-1991: --- This is indeed somehow wired. I'll fix. > Similarity#score deprecated method - javadoc reference + SimilarityDelegator > > > Key: LUCENE-1991 > URL: https://issues.apache.org/jira/browse/LUCENE-1991 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Kay Kay > Attachments: LUCENE-1991.patch > > > Old method > public float scorePayload(String fieldName, byte [] payload, int offset, > int length) > has been deprecated by - > public float scorePayload(int docId, String fieldName, int start, int end, > byte [] payload, int offset, int length) > References in PayLoadNearQuery (javadoc) changed. > Also - SimilarityDelegator overrides the new method as opposed to the > (deprecated) old one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257_o_a_l_index_test.patch Patch resubmitted confirming to generics code guidelines > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Strange Test failure every 10 TestIndexWriter test runs or so
I get often the following test failure with exactly the same position and file name, but only under windows, never in Solaris: common.test: [mkdir] Created dir: C:\Projects\lucene\trunk-full1\build\test [junit] Testsuite: org.apache.lucene.index.TestIndexWriter [junit] Tests run: 102, Failures: 0, Errors: 1, Time elapsed: 100,297sec [junit] [junit] Testcase: testExceptionDuringSync(org.apache.lucene.index.TestIndexWriter): Caused an ERROR [junit] _a.fnm [junit] java.io.FileNotFoundException: _a.fnm [junit] at org.apache.lucene.store.MockRAMDirectory.openInput(MockRAMDirectory.java:226 ) [junit] at org.apache.lucene.index.FieldInfos.(FieldInfos.java:68) [junit] at org.apache.lucene.index.SegmentReader$CoreReaders.(SegmentReader.java: 116) [junit] at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:620) [junit] at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:590) [junit] at org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:104) [junit] at org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryRead er.java:27) [junit] at org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74) [junit] at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java: 704) [junit] at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69) [junit] at org.apache.lucene.index.IndexReader.open(IndexReader.java:307) [junit] at org.apache.lucene.index.IndexReader.open(IndexReader.java:193) [junit] at org.apache.lucene.index.TestIndexWriter.testExceptionDuringSync(TestIndexWri ter.java:2723) [junit] at org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:206) [junit] [junit] [junit] Test org.apache.lucene.index.TestIndexWriter FAILED Maybe it has something to do with the deprecation removal, but it also appeared in the past, but more seldom. Any opinion? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257_o_a_l_index_test.patch o.a.lucene.index in src/test > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_index_test.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767131#action_12767131 ] Uwe Schindler commented on LUCENE-1257: --- Looks good! Committed (with some modifications and additions from my last patch): LUCENE-1257-o.a.l.util.patch 2009-10-18 01:15 PM Kay Kay 10 kB LUCENE-1257-org_apache_lucene_document.patch 2009-10-18 12:42 PM Kay Kay 29 kB LUCENE-1257_o.a.l.store.patch 2009-10-18 11:04 AM Kay Kay 12 kB LUCENE-1257_o_a_l_search_spans.patch 2009-10-18 10:52 AM Kay Kay 16 kB LUCENE-1257_o_a_l_search.patch 2009-10-18 10:39 AM Kay Kay 28 kB LUCENE-1257-IndexDeleter.patch 2009-10-18 09:21 AM Kay Kay 13 kB LUCENE-1257-iw.patch 2009-10-18 08:49 AM Kay Kay 19 kB Thanks Kay Kay! At revision: 826527 > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1257: -- Affects Version/s: (was: 2.3.1) 3.0 > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 3.0 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257-o.a.l.util.patch * MapOfSets * FieldCacheSanityChecker > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Kay updated LUCENE-1257:
Attachment: LUCENE-1257-org_apache_lucene_document.patch
{quote} Attached is a new patch with a correct generified o.a.l.util.cache
package. Now only the usage of this SimpleLRUCache should also be generified.
Kay Kay: Do you want to do this or should I do it?
{quote}
Revised patch attached that address issue with SimpleLRUCache as well
> Port to Java5
> -
>
> Key: LUCENE-1257
> URL: https://issues.apache.org/jira/browse/LUCENE-1257
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis, Examples, Index, Other, Query/Scoring,
> QueryParser, Search, Store, Term Vectors
>Affects Versions: 2.3.1
>Reporter: Cédric Champeau
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 3.0
>
> Attachments: instantiated_fieldable.patch, java5.patch,
> LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch,
> LUCENE-1257-BufferedDeletes_DocumentsWriter.patch,
> LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch,
> LUCENE-1257-ConcurrentMergeScheduler.patch,
> LUCENE-1257-DirectoryReader.patch,
> LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch,
> LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch,
> LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch,
> LUCENE-1257-NormalizeCharMap.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch,
> LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch,
> LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch,
> LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch,
> LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_search.patch,
> LUCENE-1257_o_a_l_search_spans.patch,
> LUCENE-1257_org_apache_lucene_index.patch,
> LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch,
> lucene1257surround1.patch, shinglematrixfilter_generified.patch
>
>
> For my needs I've updated Lucene so that it uses Java 5 constructs. I know
> Java 5 migration had been planned for 2.1 someday in the past, but don't know
> when it is planned now. This patch against the trunk includes :
> - most obvious generics usage (there are tons of usages of sets, ... Those
> which are commonly used have been generified)
> - PriorityQueue generification
> - replacement of indexed for loops with for each constructs
> - removal of unnececessary unboxing
> The code is to my opinion much more readable with those features (you
> actually *know* what is stored in collections reading the code, without the
> need to lookup for field definitions everytime) and it simplifies many
> algorithms.
> Note that this patch also includes an interface for the Query class. This has
> been done for my company's needs for building custom Query classes which add
> some behaviour to the base Lucene queries. It prevents multiple unnnecessary
> casts. I know this introduction is not wanted by the team, but it really
> makes our developments easier to maintain. If you don't want to use this,
> replace all /Queriable/ calls with standard /Query/.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1991) Similarity#score deprecated method - javadoc reference + SimilarityDelegator
[ https://issues.apache.org/jira/browse/LUCENE-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1991: Attachment: LUCENE-1991.patch > Similarity#score deprecated method - javadoc reference + SimilarityDelegator > > > Key: LUCENE-1991 > URL: https://issues.apache.org/jira/browse/LUCENE-1991 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Kay Kay > Attachments: LUCENE-1991.patch > > > Old method > public float scorePayload(String fieldName, byte [] payload, int offset, > int length) > has been deprecated by - > public float scorePayload(int docId, String fieldName, int start, int end, > byte [] payload, int offset, int length) > References in PayLoadNearQuery (javadoc) changed. > Also - SimilarityDelegator overrides the new method as opposed to the > (deprecated) old one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Created: (LUCENE-1991) Similarity#score deprecated method - javadoc reference + SimilarityDelegator
Similarity#score deprecated method - javadoc reference + SimilarityDelegator Key: LUCENE-1991 URL: https://issues.apache.org/jira/browse/LUCENE-1991 Project: Lucene - Java Issue Type: Improvement Reporter: Kay Kay Attachments: LUCENE-1991.patch Old method public float scorePayload(String fieldName, byte [] payload, int offset, int length) has been deprecated by - public float scorePayload(int docId, String fieldName, int start, int end, byte [] payload, int offset, int length) References in PayLoadNearQuery (javadoc) changed. Also - SimilarityDelegator overrides the new method as opposed to the (deprecated) old one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257_o.a.l.store.patch > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o.a.l.store.patch, LUCENE-1257_o_a_l_search.patch, > LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257_o_a_l_search_spans.patch o.a.l.search.spans - generics added > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_o_a_l_search_spans.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257_o_a_l_search.patch o.a.l.search package - generified > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_o_a_l_search.patch, LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257-IndexDeleter.patch IndexDelete (Policy) and stuff > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767087#action_12767087 ] Kay Kay commented on LUCENE-1257: - Uwe: Please feel free to go ahead and do it and commit it, that I can pick up the diff. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-IndexDeleter.patch, LUCENE-1257-iw.patch, > LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1257: -- Attachment: LUCENE-1257-org_apache_lucene_document.patch Attached is a new patch with a correct generified o.a.l.util.cache package. Now only the usage of this SimpleLRUCache should also be generified. Kay Kay: Do you want to do this or should I do it? > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-iw.patch, LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: 2.9.1
ah! Thanks Yonik! -John On Sun, Oct 18, 2009 at 6:32 AM, Yonik Seeley wrote: > On Sun, Oct 18, 2009 at 1:43 AM, John Wang wrote: > > Maybe it is not a big deal. But I would still like to know why in > > MultiTermDocs, if term is not null, termDocs(term) is not called, rather > > termDocs() is. > > That would work, but it would sometimes be less efficient. > > By calling termDocs() only, MultiTermDocs can use the more efficient > seek(termEnum) rather than seek(term) that termDocs(term) would > otherwise use. > > -Yonik > http://www.lucidimagination.com > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257-iw.patch * Mostly with IndexWriter > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-iw.patch, LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1458) Further steps towards flexible indexing
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767073#action_12767073
]
Mark Miller commented on LUCENE-1458:
-
bq. Are they causing OOMs with TestIndexReaderReopen? (I haven't tried yet).
Yes - they both def need polish too - I just got them working (passing all the
tests), but havn't really finished them.
> Further steps towards flexible indexing
> ---
>
> Key: LUCENE-1458
> URL: https://issues.apache.org/jira/browse/LUCENE-1458
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index
>Affects Versions: 2.9
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2
>
>
> I attached a very rough checkpoint of my current patch, to get early
> feedback. All tests pass, though back compat tests don't pass due to
> changes to package-private APIs plus certain bugs in tests that
> happened to work (eg call TermPostions.nextPosition() too many times,
> which the new API asserts against).
> [Aside: I think, when we commit changes to package-private APIs such
> that back-compat tests don't pass, we could go back, make a branch on
> the back-compat tag, commit changes to the tests to use the new
> package private APIs on that branch, then fix nightly build to use the
> tip of that branch?o]
> There's still plenty to do before this is committable! This is a
> rather large change:
> * Switches to a new more efficient terms dict format. This still
> uses tii/tis files, but the tii only stores term & long offset
> (not a TermInfo). At seek points, tis encodes term & freq/prox
> offsets absolutely instead of with deltas delta. Also, tis/tii
> are structured by field, so we don't have to record field number
> in every term.
> .
> On first 1 M docs of Wikipedia, tii file is 36% smaller (0.99 MB
> -> 0.64 MB) and tis file is 9% smaller (75.5 MB -> 68.5 MB).
> .
> RAM usage when loading terms dict index is significantly less
> since we only load an array of offsets and an array of String (no
> more TermInfo array). It should be faster to init too.
> .
> This part is basically done.
> * Introduces modular reader codec that strongly decouples terms dict
> from docs/positions readers. EG there is no more TermInfo used
> when reading the new format.
> .
> There's nice symmetry now between reading & writing in the codec
> chain -- the current docs/prox format is captured in:
> {code}
> FormatPostingsTermsDictWriter/Reader
> FormatPostingsDocsWriter/Reader (.frq file) and
> FormatPostingsPositionsWriter/Reader (.prx file).
> {code}
> This part is basically done.
> * Introduces a new "flex" API for iterating through the fields,
> terms, docs and positions:
> {code}
> FieldProducer -> TermsEnum -> DocsEnum -> PostingsEnum
> {code}
> This replaces TermEnum/Docs/Positions. SegmentReader emulates the
> old API on top of the new API to keep back-compat.
>
> Next steps:
> * Plug in new codecs (pulsing, pfor) to exercise the modularity /
> fix any hidden assumptions.
> * Expose new API out of IndexReader, deprecate old API but emulate
> old API on top of new one, switch all core/contrib users to the
> new API.
> * Maybe switch to AttributeSources as the base class for TermsEnum,
> DocsEnum, PostingsEnum -- this would give readers API flexibility
> (not just index-file-format flexibility). EG if someone wanted
> to store payload at the term-doc level instead of
> term-doc-position level, you could just add a new attribute.
> * Test performance & iterate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767072#action_12767072 ] Uwe Schindler commented on LUCENE-1257: --- bq. More set of patches in org.apache.lucene.document You mean not only document? I looked through it: The o.a.l.util.cache is not ideal: The whole classes should take a parameter for the cache and not be fixed to . This was on my list to fix, so I would leave out the whole cache package in this patch and fix it myself. > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1458) Further steps towards flexible indexing
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767071#action_12767071
]
Michael McCandless commented on LUCENE-1458:
bq. Pulsing is more of an issue because of the Document caching...
Yeah, we probably need to measure cache size by RAM usage not shear count.
And, make it settable when you instantiate the codec.
bq. Sep and Pulsing still need to be trimmed down though
Are they causing OOMs with TestIndexReaderReopen? (I haven't tried yet).
> Further steps towards flexible indexing
> ---
>
> Key: LUCENE-1458
> URL: https://issues.apache.org/jira/browse/LUCENE-1458
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index
>Affects Versions: 2.9
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2
>
>
> I attached a very rough checkpoint of my current patch, to get early
> feedback. All tests pass, though back compat tests don't pass due to
> changes to package-private APIs plus certain bugs in tests that
> happened to work (eg call TermPostions.nextPosition() too many times,
> which the new API asserts against).
> [Aside: I think, when we commit changes to package-private APIs such
> that back-compat tests don't pass, we could go back, make a branch on
> the back-compat tag, commit changes to the tests to use the new
> package private APIs on that branch, then fix nightly build to use the
> tip of that branch?o]
> There's still plenty to do before this is committable! This is a
> rather large change:
> * Switches to a new more efficient terms dict format. This still
> uses tii/tis files, but the tii only stores term & long offset
> (not a TermInfo). At seek points, tis encodes term & freq/prox
> offsets absolutely instead of with deltas delta. Also, tis/tii
> are structured by field, so we don't have to record field number
> in every term.
> .
> On first 1 M docs of Wikipedia, tii file is 36% smaller (0.99 MB
> -> 0.64 MB) and tis file is 9% smaller (75.5 MB -> 68.5 MB).
> .
> RAM usage when loading terms dict index is significantly less
> since we only load an array of offsets and an array of String (no
> more TermInfo array). It should be faster to init too.
> .
> This part is basically done.
> * Introduces modular reader codec that strongly decouples terms dict
> from docs/positions readers. EG there is no more TermInfo used
> when reading the new format.
> .
> There's nice symmetry now between reading & writing in the codec
> chain -- the current docs/prox format is captured in:
> {code}
> FormatPostingsTermsDictWriter/Reader
> FormatPostingsDocsWriter/Reader (.frq file) and
> FormatPostingsPositionsWriter/Reader (.prx file).
> {code}
> This part is basically done.
> * Introduces a new "flex" API for iterating through the fields,
> terms, docs and positions:
> {code}
> FieldProducer -> TermsEnum -> DocsEnum -> PostingsEnum
> {code}
> This replaces TermEnum/Docs/Positions. SegmentReader emulates the
> old API on top of the new API to keep back-compat.
>
> Next steps:
> * Plug in new codecs (pulsing, pfor) to exercise the modularity /
> fix any hidden assumptions.
> * Expose new API out of IndexReader, deprecate old API but emulate
> old API on top of new one, switch all core/contrib users to the
> new API.
> * Maybe switch to AttributeSources as the base class for TermsEnum,
> DocsEnum, PostingsEnum -- this would give readers API flexibility
> (not just index-file-format flexibility). EG if someone wanted
> to store payload at the term-doc level instead of
> term-doc-position level, you could just add a new attribute.
> * Test performance & iterate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated LUCENE-1257: Attachment: LUCENE-1257-org_apache_lucene_document.patch More set of patches in org.apache.lucene.document . > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-NormalizeCharMap.patch, > LUCENE-1257-org_apache_lucene_document.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1458) Further steps towards flexible indexing
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767068#action_12767068
]
Mark Miller commented on LUCENE-1458:
-
Nice! Sep and Pulsing still need to be trimmed down though - or we consider
their bloat acceptable (they still don't pass). Sep especially should be pretty
trimable I think. Pulsing is more of an issue because of the Document caching...
> Further steps towards flexible indexing
> ---
>
> Key: LUCENE-1458
> URL: https://issues.apache.org/jira/browse/LUCENE-1458
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index
>Affects Versions: 2.9
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2
>
>
> I attached a very rough checkpoint of my current patch, to get early
> feedback. All tests pass, though back compat tests don't pass due to
> changes to package-private APIs plus certain bugs in tests that
> happened to work (eg call TermPostions.nextPosition() too many times,
> which the new API asserts against).
> [Aside: I think, when we commit changes to package-private APIs such
> that back-compat tests don't pass, we could go back, make a branch on
> the back-compat tag, commit changes to the tests to use the new
> package private APIs on that branch, then fix nightly build to use the
> tip of that branch?o]
> There's still plenty to do before this is committable! This is a
> rather large change:
> * Switches to a new more efficient terms dict format. This still
> uses tii/tis files, but the tii only stores term & long offset
> (not a TermInfo). At seek points, tis encodes term & freq/prox
> offsets absolutely instead of with deltas delta. Also, tis/tii
> are structured by field, so we don't have to record field number
> in every term.
> .
> On first 1 M docs of Wikipedia, tii file is 36% smaller (0.99 MB
> -> 0.64 MB) and tis file is 9% smaller (75.5 MB -> 68.5 MB).
> .
> RAM usage when loading terms dict index is significantly less
> since we only load an array of offsets and an array of String (no
> more TermInfo array). It should be faster to init too.
> .
> This part is basically done.
> * Introduces modular reader codec that strongly decouples terms dict
> from docs/positions readers. EG there is no more TermInfo used
> when reading the new format.
> .
> There's nice symmetry now between reading & writing in the codec
> chain -- the current docs/prox format is captured in:
> {code}
> FormatPostingsTermsDictWriter/Reader
> FormatPostingsDocsWriter/Reader (.frq file) and
> FormatPostingsPositionsWriter/Reader (.prx file).
> {code}
> This part is basically done.
> * Introduces a new "flex" API for iterating through the fields,
> terms, docs and positions:
> {code}
> FieldProducer -> TermsEnum -> DocsEnum -> PostingsEnum
> {code}
> This replaces TermEnum/Docs/Positions. SegmentReader emulates the
> old API on top of the new API to keep back-compat.
>
> Next steps:
> * Plug in new codecs (pulsing, pfor) to exercise the modularity /
> fix any hidden assumptions.
> * Expose new API out of IndexReader, deprecate old API but emulate
> old API on top of new one, switch all core/contrib users to the
> new API.
> * Maybe switch to AttributeSources as the base class for TermsEnum,
> DocsEnum, PostingsEnum -- this would give readers API flexibility
> (not just index-file-format flexibility). EG if someone wanted
> to store payload at the term-doc level instead of
> term-doc-position level, you could just add a new attribute.
> * Test performance & iterate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: 2.9.1
On Sun, Oct 18, 2009 at 1:43 AM, John Wang wrote: > Maybe it is not a big deal. But I would still like to know why in > MultiTermDocs, if term is not null, termDocs(term) is not called, rather > termDocs() is. That would work, but it would sometimes be less efficient. By calling termDocs() only, MultiTermDocs can use the more efficient seek(termEnum) rather than seek(term) that termDocs(term) would otherwise use. -Yonik http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
[ https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767064#action_12767064 ] Michael McCandless commented on LUCENE-1987: bq. Or make the Analyzers final? +1 > Remove rest of analysis deprecations (Token, CharacterCache) > > > Key: LUCENE-1987 > URL: https://issues.apache.org/jira/browse/LUCENE-1987 > Project: Lucene - Java > Issue Type: Task > Components: Analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.0 > > Attachments: LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch > > > These removes the rest of the deprecations in the analysis package: > - -Token's termText field-- (DONE) > - -eventually un-deprecate ctors of Token taking Strings (they are still > useful) -> if yes remove deprec in 2.9.1- (DONE) > - -remove CharacterCache and use Character.valueOf() from Java5- (DONE) > - Stopwords lists > - Remove the backwards settings from analyzers (acronym, posIncr,...). They > are deprecated, but we still have the VERSION constants. Do not know, how to > proceed. Keep the settings alive for index compatibility? Or remove it > together with the version constants (which were undeprecated). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
[ https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767063#action_12767063 ] Michael McCandless commented on LUCENE-1987: bq. How should we handle the deprecated settings inside? For "replace invalid acronym" in StandardAnalyzer, there is no version setting that enables that currently, so I'm afraid we must keep those until 4.0 (since they impact your index by altering analysis)? Or, maybe we could add a Versions.LUCENE_23, which'd re-enable that bug (the default for that setting changed to "true" (= fix the bug) in 2.4). Hmm. For "stop position increments" in StandardAnalyzer, I think we should remove the direct getter/setters and expose only Versions.LUCENE_24 to get back to that behavior? StopFilter should keep its "stop position increments" setting (it's not deprecated). > Remove rest of analysis deprecations (Token, CharacterCache) > > > Key: LUCENE-1987 > URL: https://issues.apache.org/jira/browse/LUCENE-1987 > Project: Lucene - Java > Issue Type: Task > Components: Analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.0 > > Attachments: LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch > > > These removes the rest of the deprecations in the analysis package: > - -Token's termText field-- (DONE) > - -eventually un-deprecate ctors of Token taking Strings (they are still > useful) -> if yes remove deprec in 2.9.1- (DONE) > - -remove CharacterCache and use Character.valueOf() from Java5- (DONE) > - Stopwords lists > - Remove the backwards settings from analyzers (acronym, posIncr,...). They > are deprecated, but we still have the VERSION constants. Do not know, how to > proceed. Keep the settings alive for index compatibility? Or remove it > together with the version constants (which were undeprecated). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1458) Further steps towards flexible indexing
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767056#action_12767056
]
Michael McCandless commented on LUCENE-1458:
I just committed fix for a major memory cost during TestIndexReaderReopen.
The new terms dict index uses fixed byte[] blocks to hold the UTF8 bytes, of
size 32 KB currently. But for a tiny segment this is very wasteful. So I
fixed it to trim down the last byte[] block to free up the unused space. I
think TestIndexReaderReopen should no longer hit OOMs.
> Further steps towards flexible indexing
> ---
>
> Key: LUCENE-1458
> URL: https://issues.apache.org/jira/browse/LUCENE-1458
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index
>Affects Versions: 2.9
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458-back-compat.patch,
> LUCENE-1458-back-compat.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch,
> LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.patch, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2,
> LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2, LUCENE-1458.tar.bz2
>
>
> I attached a very rough checkpoint of my current patch, to get early
> feedback. All tests pass, though back compat tests don't pass due to
> changes to package-private APIs plus certain bugs in tests that
> happened to work (eg call TermPostions.nextPosition() too many times,
> which the new API asserts against).
> [Aside: I think, when we commit changes to package-private APIs such
> that back-compat tests don't pass, we could go back, make a branch on
> the back-compat tag, commit changes to the tests to use the new
> package private APIs on that branch, then fix nightly build to use the
> tip of that branch?o]
> There's still plenty to do before this is committable! This is a
> rather large change:
> * Switches to a new more efficient terms dict format. This still
> uses tii/tis files, but the tii only stores term & long offset
> (not a TermInfo). At seek points, tis encodes term & freq/prox
> offsets absolutely instead of with deltas delta. Also, tis/tii
> are structured by field, so we don't have to record field number
> in every term.
> .
> On first 1 M docs of Wikipedia, tii file is 36% smaller (0.99 MB
> -> 0.64 MB) and tis file is 9% smaller (75.5 MB -> 68.5 MB).
> .
> RAM usage when loading terms dict index is significantly less
> since we only load an array of offsets and an array of String (no
> more TermInfo array). It should be faster to init too.
> .
> This part is basically done.
> * Introduces modular reader codec that strongly decouples terms dict
> from docs/positions readers. EG there is no more TermInfo used
> when reading the new format.
> .
> There's nice symmetry now between reading & writing in the codec
> chain -- the current docs/prox format is captured in:
> {code}
> FormatPostingsTermsDictWriter/Reader
> FormatPostingsDocsWriter/Reader (.frq file) and
> FormatPostingsPositionsWriter/Reader (.prx file).
> {code}
> This part is basically done.
> * Introduces a new "flex" API for iterating through the fields,
> terms, docs and positions:
> {code}
> FieldProducer -> TermsEnum -> DocsEnum -> PostingsEnum
> {code}
> This replaces TermEnum/Docs/Positions. SegmentReader emulates the
> old API on top of the new API to keep back-compat.
>
> Next steps:
> * Plug in new codecs (pulsing, pfor) to exercise the modularity /
> fix any hidden assumptions.
> * Expose new API out of IndexReader, deprecate old API but emulate
> old API on top of new one, switch all core/contrib users to the
> new API.
> * Maybe switch to AttributeSources as the base class for TermsEnum,
> DocsEnum, PostingsEnum -- this would give readers API flexibility
> (not just index-file-format flexibility). EG if someone wanted
> to store payload at the term-doc level instead of
> term-doc-position level, you could just add a new attribute.
> * Test performance & iterate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Created: (LUCENE-1990) Add unsigned packed int impls in oal.util
Add unsigned packed int impls in oal.util
-
Key: LUCENE-1990
URL: https://issues.apache.org/jira/browse/LUCENE-1990
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Michael McCandless
Priority: Minor
There are various places in Lucene that could take advantage of an
efficient packed unsigned int/long impl. EG the terms dict index in
the standard codec in LUCENE-1458 could subsantially reduce it's RAM
usage. FieldCache.StringIndex could as well. And I think "load into
RAM" codecs like the one in TestExternalCodecs could use this too.
I'm picturing something very basic like:
{code}
interface PackedUnsignedLongs {
long get(long index);
void set(long index, long value);
}
{code}
Plus maybe an iterator for getting and maybe also for setting. If it
helps, most of the usages of this inside Lucene will be "write once"
so eg the set could make that an assumption/requirement.
And a factory somewhere:
{code}
PackedUnsignedLongs create(int count, long maxValue);
{code}
I think we should simply autogen the code (we can start from the
autogen code in LUCENE-1410), or, if there is an good existing impl
that has a compatible license that'd be great.
I don't have time near-term to do this... so if anyone has the itch,
please jump!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
[ https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767049#action_12767049 ] Uwe Schindler edited comment on LUCENE-1987 at 10/18/09 5:04 AM: - Mike: You invented the VERSION constants for StandardAnalyzer and so on. How should we handle the deprecated settings inside? Just remove the get/setters and only use the version constant to enable the backwards settings? If I remove these settings internally in StopAnalyzer and StopFilter and Standard*, too, I also have to remove some version support. How would you proceed? Furthermore: The "deprecated" check for overridden tokenStream methods to fix this bug, if somebody subclasses a core-Analyzer, what to do with them. As the tokenStream methods is not deprecated in favour of reusableTokenStream, how to prevent this in future. Keep this reflection checks? Or make the Analyzers final? was (Author: thetaphi): Mike: You invented the VERSION constants for StandardAnalyzer and so on. How should we handle the deprecated settings inside? Just remove the get/setters and only use the version constant to enable the backwards settings? If I remove these settings internally in StopAnalyzer and StopFilter and Standard*, too, I also have to remove some version support. How would you proceed? > Remove rest of analysis deprecations (Token, CharacterCache) > > > Key: LUCENE-1987 > URL: https://issues.apache.org/jira/browse/LUCENE-1987 > Project: Lucene - Java > Issue Type: Task > Components: Analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.0 > > Attachments: LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch > > > These removes the rest of the deprecations in the analysis package: > - -Token's termText field-- (DONE) > - -eventually un-deprecate ctors of Token taking Strings (they are still > useful) -> if yes remove deprec in 2.9.1- (DONE) > - -remove CharacterCache and use Character.valueOf() from Java5- (DONE) > - Stopwords lists > - Remove the backwards settings from analyzers (acronym, posIncr,...). They > are deprecated, but we still have the VERSION constants. Do not know, how to > proceed. Keep the settings alive for index compatibility? Or remove it > together with the version constants (which were undeprecated). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
[ https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767049#action_12767049 ] Uwe Schindler commented on LUCENE-1987: --- Mike: You invented the VERSION constants for StandardAnalyzer and so on. How should we handle the deprecated settings inside? Just remove the get/setters and only use the version constant to enable the backwards settings? If I remove these settings internally in StopAnalyzer and StopFilter and Standard*, too, I also have to remove some version support. How would you proceed? > Remove rest of analysis deprecations (Token, CharacterCache) > > > Key: LUCENE-1987 > URL: https://issues.apache.org/jira/browse/LUCENE-1987 > Project: Lucene - Java > Issue Type: Task > Components: Analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.0 > > Attachments: LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch > > > These removes the rest of the deprecations in the analysis package: > - -Token's termText field-- (DONE) > - -eventually un-deprecate ctors of Token taking Strings (they are still > useful) -> if yes remove deprec in 2.9.1- (DONE) > - -remove CharacterCache and use Character.valueOf() from Java5- (DONE) > - Stopwords lists > - Remove the backwards settings from analyzers (acronym, posIncr,...). They > are deprecated, but we still have the VERSION constants. Do not know, how to > proceed. Keep the settings alive for index compatibility? Or remove it > together with the version constants (which were undeprecated). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
[ https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1987: -- Description: These removes the rest of the deprecations in the analysis package: - -Token's termText field-- (DONE) - -eventually un-deprecate ctors of Token taking Strings (they are still useful) -> if yes remove deprec in 2.9.1- (DONE) - -remove CharacterCache and use Character.valueOf() from Java5- (DONE) - Stopwords lists - Remove the backwards settings from analyzers (acronym, posIncr,...). They are deprecated, but we still have the VERSION constants. Do not know, how to proceed. Keep the settings alive for index compatibility? Or remove it together with the version constants (which were undeprecated). was: These removes the rest of the deprecations in the analysis package: - Token's termText field - eventually un-deprecate ctors of Token taking Strings (they are still useful) -> if yes remove deprec in 2.9.1 - remove CharacterCache and use Character.valueOf() from Java5 - Some Analyzers have stopword lists in wrong format (HashMaps) > Remove rest of analysis deprecations (Token, CharacterCache) > > > Key: LUCENE-1987 > URL: https://issues.apache.org/jira/browse/LUCENE-1987 > Project: Lucene - Java > Issue Type: Task > Components: Analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.0 > > Attachments: LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch > > > These removes the rest of the deprecations in the analysis package: > - -Token's termText field-- (DONE) > - -eventually un-deprecate ctors of Token taking Strings (they are still > useful) -> if yes remove deprec in 2.9.1- (DONE) > - -remove CharacterCache and use Character.valueOf() from Java5- (DONE) > - Stopwords lists > - Remove the backwards settings from analyzers (acronym, posIncr,...). They > are deprecated, but we still have the VERSION constants. Do not know, how to > proceed. Keep the settings alive for index compatibility? Or remove it > together with the version constants (which were undeprecated). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
[ https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767042#action_12767042 ] Uwe Schindler commented on LUCENE-1987: --- Committed revision: 826404 and also in 2.9 branch. > Remove rest of analysis deprecations (Token, CharacterCache) > > > Key: LUCENE-1987 > URL: https://issues.apache.org/jira/browse/LUCENE-1987 > Project: Lucene - Java > Issue Type: Task > Components: Analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.0 > > Attachments: LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch > > > These removes the rest of the deprecations in the analysis package: > - Token's termText field > - eventually un-deprecate ctors of Token taking Strings (they are still > useful) -> if yes remove deprec in 2.9.1 > - remove CharacterCache and use Character.valueOf() from Java5 > - Some Analyzers have stopword lists in wrong format (HashMaps) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Resolved: (LUCENE-1988) CharacterCache - references deleted
[ https://issues.apache.org/jira/browse/LUCENE-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-1988. --- Resolution: Fixed Resolved as part of parent issue. > CharacterCache - references deleted > > > Key: LUCENE-1988 > URL: https://issues.apache.org/jira/browse/LUCENE-1988 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Kay Kay >Assignee: Uwe Schindler > Attachments: LUCENE-1988.patch > > > CharacterCache is deprecated by Character.valueOf(c) . Hence the latter is > chosen over the former. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1987) Remove rest of analysis deprecations (Token, CharacterCache)
[ https://issues.apache.org/jira/browse/LUCENE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1987: -- Attachment: LUCENE-1987.patch New patch. Will commit soon (+bw branch). I will also commit the un-depreactions to 2.9 branch. Still open are the StopFilter/StopAnalyzer patches (not sure, how to proceed here). > Remove rest of analysis deprecations (Token, CharacterCache) > > > Key: LUCENE-1987 > URL: https://issues.apache.org/jira/browse/LUCENE-1987 > Project: Lucene - Java > Issue Type: Task > Components: Analysis >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.0 > > Attachments: LUCENE-1987.patch, LUCENE-1987.patch, LUCENE-1987.patch > > > These removes the rest of the deprecations in the analysis package: > - Token's termText field > - eventually un-deprecate ctors of Token taking Strings (they are still > useful) -> if yes remove deprec in 2.9.1 > - remove CharacterCache and use Character.valueOf() from Java5 > - Some Analyzers have stopword lists in wrong format (HashMaps) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Resolved: (LUCENE-1989) CharArraySet cannot be made generic, because it violates the Set interface
[
https://issues.apache.org/jira/browse/LUCENE-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-1989.
---
Resolution: Fixed
Assignee: Uwe Schindler
Committed revision: 826395
> CharArraySet cannot be made generic, because it violates the Set
> interface
> --
>
> Key: LUCENE-1989
> URL: https://issues.apache.org/jira/browse/LUCENE-1989
> Project: Lucene - Java
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 3.0
>
> Attachments: LUCENE-1989.patch, LUCENE-1989.patch
>
>
> I tried to make CharArraySet using generics (extends AbstractSet) but
> this is not possible, as it e.g. returns sometimes String instances in the
> Iterator instead of []. Also its addAll method accepts both String and
> char[]. I think this class is a complete mis-design and violates almost
> everything (sorry).
> What to do? Make it Set or just place a big @SuppressWarnings("unchecked">
> in front of it?
> Because of this problem also a lot of Set declarations inside StopAnalyzer
> cannot be made generic as you never know whats inside.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1989) CharArraySet cannot be made generic, because it violates the Set interface
[
https://issues.apache.org/jira/browse/LUCENE-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1989:
--
Attachment: LUCENE-1989.patch
Add some java docs. Will commit now.
> CharArraySet cannot be made generic, because it violates the Set
> interface
> --
>
> Key: LUCENE-1989
> URL: https://issues.apache.org/jira/browse/LUCENE-1989
> Project: Lucene - Java
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Uwe Schindler
> Fix For: 3.0
>
> Attachments: LUCENE-1989.patch, LUCENE-1989.patch
>
>
> I tried to make CharArraySet using generics (extends AbstractSet) but
> this is not possible, as it e.g. returns sometimes String instances in the
> Iterator instead of []. Also its addAll method accepts both String and
> char[]. I think this class is a complete mis-design and violates almost
> everything (sorry).
> What to do? Make it Set or just place a big @SuppressWarnings("unchecked">
> in front of it?
> Because of this problem also a lot of Set declarations inside StopAnalyzer
> cannot be made generic as you never know whats inside.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: 2.9.1
On Sun, Oct 18, 2009 at 1:43 AM, John Wang wrote: > Maybe it is not a big deal. But I would still like to know why in > MultiTermDocs, if term is not null, termDocs(term) is not called, rather > termDocs() is. John are you referring to the protected TermDocs termDocs(IndexReader reader) method in DirectoryReader.MultiTermDocs? Mike - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Resolved: (LUCENE-1986) NPE in NearSpansUnordered from PayloadNearQuery
[ https://issues.apache.org/jira/browse/LUCENE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1986. Resolution: Fixed Thanks Peter and Mark! > NPE in NearSpansUnordered from PayloadNearQuery > --- > > Key: LUCENE-1986 > URL: https://issues.apache.org/jira/browse/LUCENE-1986 > Project: Lucene - Java > Issue Type: Bug > Components: Search >Affects Versions: 2.9 >Reporter: Peter Keegan >Assignee: Michael McCandless > Fix For: 2.9.1, 3.0 > > Attachments: LUCENE-1986.patch, LUCENE-1986.patch, > TestPayloadNearQuery1.java > > > The following query causes a NPE in NearSpansUnordered, and is reproducible > with the the attached unit test. The failure occurs on the last document > scored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767033#action_12767033 ] Uwe Schindler commented on LUCENE-1257: --- Committed LUCENE-1257_org_apache_lucene_index.patch At revision: 826389 > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1986) NPE in NearSpansUnordered from PayloadNearQuery
[ https://issues.apache.org/jira/browse/LUCENE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1986: --- Attachment: LUCENE-1986.patch Thanks for the test case Peter and for the fix Mark! I attached a patch that merges the test case into the existing TestPayloadNearQuery, merges in Mark's fix, fixes the whitespace in that test, and adds a CHANGES entry. I'll commit shortly & back port. > NPE in NearSpansUnordered from PayloadNearQuery > --- > > Key: LUCENE-1986 > URL: https://issues.apache.org/jira/browse/LUCENE-1986 > Project: Lucene - Java > Issue Type: Bug > Components: Search >Affects Versions: 2.9 >Reporter: Peter Keegan >Assignee: Michael McCandless > Fix For: 2.9.1, 3.0 > > Attachments: LUCENE-1986.patch, LUCENE-1986.patch, > TestPayloadNearQuery1.java > > > The following query causes a NPE in NearSpansUnordered, and is reproducible > with the the attached unit test. The failure occurs on the last document > scored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1257: -- Attachment: LUCENE-1257_org_apache_lucene_index.patch Whitespace-cleanup of your patch. See also [http://www.lucidimagination.com/search/document/62fe00098351dbe3/whitespace_inside_generics_parameters] for how Lucene should format generics parameters. I will apply when all tests are run. Thank you for the hard work, that not really fun to convert all this :-( > Port to Java5 > - > > Key: LUCENE-1257 > URL: https://issues.apache.org/jira/browse/LUCENE-1257 > Project: Lucene - Java > Issue Type: Improvement > Components: Analysis, Examples, Index, Other, Query/Scoring, > QueryParser, Search, Store, Term Vectors >Affects Versions: 2.3.1 >Reporter: Cédric Champeau >Assignee: Uwe Schindler >Priority: Minor > Fix For: 3.0 > > Attachments: instantiated_fieldable.patch, java5.patch, > LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, > LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, > LUCENE-1257-CheckIndex.patch, LUCENE-1257-CompoundFileReaderWriter.patch, > LUCENE-1257-ConcurrentMergeScheduler.patch, > LUCENE-1257-DirectoryReader.patch, > LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, > LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, > LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-SegmentInfos.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, > LUCENE-1257-StringBuffer.patch, LUCENE-1257-WordListLoader.patch, > LUCENE-1257_BooleanFilter_Generics.patch, LUCENE-1257_messages.patch, > LUCENE-1257_org_apache_lucene_index.patch, > LUCENE-1257_org_apache_lucene_index.patch, lucene1257surround1.patch, > lucene1257surround1.patch, shinglematrixfilter_generified.patch > > > For my needs I've updated Lucene so that it uses Java 5 constructs. I know > Java 5 migration had been planned for 2.1 someday in the past, but don't know > when it is planned now. This patch against the trunk includes : > - most obvious generics usage (there are tons of usages of sets, ... Those > which are commonly used have been generified) > - PriorityQueue generification > - replacement of indexed for loops with for each constructs > - removal of unnececessary unboxing > The code is to my opinion much more readable with those features (you > actually *know* what is stored in collections reading the code, without the > need to lookup for field definitions everytime) and it simplifies many > algorithms. > Note that this patch also includes an interface for the Query class. This has > been done for my company's needs for building custom Query classes which add > some behaviour to the base Lucene queries. It prevents multiple unnnecessary > casts. I know this introduction is not wanted by the team, but it really > makes our developments easier to maintain. If you don't want to use this, > replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: 2.9.1
Nice :) Fix looks good... I'll commit soon. Thanks! Mike On Sat, Oct 17, 2009 at 1:19 PM, Mark Miller wrote: > Not that I have any comfort with spans - but I'm good with a shovel ;) > > Mark Miller wrote: >> Got it I think. >> >> Michael McCandless wrote: >> >>> I've marked fix for 2.9.1. Can someone w/ comfort in this (span >>> queries) have a look? >>> >>> If nobody jumps after a while I'll try to dig in... >>> >>> Mike >>> >>> On Sat, Oct 17, 2009 at 11:11 AM, Yonik Seeley >>> wrote: >>> >>> On Wed, Oct 14, 2009 at 5:39 PM, Michael McCandless wrote: > I can cut the 2.9.1 release, but... should we wait a bit to see > whether other issues come up? > > I took a quick peek at the test code provided by Peter... and this certainly looks like a bug: https://issues.apache.org/jira/browse/LUCENE-1986 I'm heads down on the Solr release right now though, so I haven't had time to dig in. -Yonik http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org >>> - >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>> >>> >>> >> >> > > > -- > - Mark > > http://www.lucidimagination.com > > > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Assigned: (LUCENE-1986) NPE in NearSpansUnordered from PayloadNearQuery
[ https://issues.apache.org/jira/browse/LUCENE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-1986: -- Assignee: Michael McCandless > NPE in NearSpansUnordered from PayloadNearQuery > --- > > Key: LUCENE-1986 > URL: https://issues.apache.org/jira/browse/LUCENE-1986 > Project: Lucene - Java > Issue Type: Bug > Components: Search >Affects Versions: 2.9 >Reporter: Peter Keegan >Assignee: Michael McCandless > Fix For: 2.9.1, 3.0 > > Attachments: LUCENE-1986.patch, TestPayloadNearQuery1.java > > > The following query causes a NPE in NearSpansUnordered, and is reproducible > with the the attached unit test. The failure occurs on the last document > scored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
