[jira] Commented: (LUCENE-455) FieldsReader does not regard offset and position flags
[ http://issues.apache.org/jira/browse/LUCENE-455?page=comments#action_12332492 ] Bernhard Messer commented on LUCENE-455: Frank, thanks for the patch. I've reviewed it and commited it. Bernhard > FieldsReader does not regard offset and position flags > -- > > Key: LUCENE-455 > URL: http://issues.apache.org/jira/browse/LUCENE-455 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Reporter: Frank Steinmann > Priority: Minor > Attachments: FieldsReader.java > > When creating a Field the FieldsReader looks at the storeTermVector flag of > the FieldInfo. If true Field.TermVector.YES is used as parameter. But it > should be checked if storeOffsetWithTermVector and > storePositionWithTermVector are set and Field.TermVector.WITH_OFFSETS, > ...WITH_POSITIONS, or ...WITH_POSITIONS_OFFSETS should be used as appropriate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LUCENE-455) FieldsReader does not regard offset and position flags
[ http://issues.apache.org/jira/browse/LUCENE-455?page=all ] Bernhard Messer closed LUCENE-455: -- Fix Version: CVS Nightly - Specify date in submission Resolution: Fixed > FieldsReader does not regard offset and position flags > -- > > Key: LUCENE-455 > URL: http://issues.apache.org/jira/browse/LUCENE-455 > Project: Lucene - Java > Type: Bug > Components: Index > Versions: 1.9 > Reporter: Frank Steinmann > Priority: Minor > Fix For: CVS Nightly - Specify date in submission > Attachments: FieldsReader.java > > When creating a Field the FieldsReader looks at the storeTermVector flag of > the FieldInfo. If true Field.TermVector.YES is used as parameter. But it > should be checked if storeOffsetWithTermVector and > storePositionWithTermVector are set and Field.TermVector.WITH_OFFSETS, > ...WITH_POSITIONS, or ...WITH_POSITIONS_OFFSETS should be used as appropriate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LUCENE-306) [PATCH]multiple wildcards ? at the end of search pattern return incorrect hits
[ http://issues.apache.org/jira/browse/LUCENE-306?page=all ]
Bernhard Messer closed LUCENE-306:
--
Resolution: Fixed
Assign To: (was: Lucene Developers)
WildcardQuery doesn't match 'cat' for queries like 'ca??' anylonger.
> [PATCH]multiple wildcards ? at the end of search pattern return incorrect hits
> --
>
> Key: LUCENE-306
> URL: http://issues.apache.org/jira/browse/LUCENE-306
> Project: Lucene - Java
> Type: Bug
> Components: Search
> Versions: 1.4
> Environment: Operating System: other
> Platform: Other
> Reporter: Xiaozheng Ma
>
> The problem is if you search on "ca??", the hit includes 'cat', 'CA',
> etc, while the user only wants 4 letter words start with CA, such as
> 'card', 'cash', to be returned. This happens only when multiple '?' at
> the end of search pattern. The solution is to check if the word that is
> matching against search pattern ends while there is still '?' left. If
> this is the case, match should return false.
> Attached is the patch code I generated use 'diff'
>
> --- WildcardTermEnum.org 2004-05-11 11:42:10.0 -0400
> +++ WildcardTermEnum.java 2004-11-08 14:35:14.823610500 -0500
> @@ -132,6 +132,10 @@
> }
> else
> {
> + //to prevent "cat" matches "ca??"
> + if(wildchar == WILDCARD_CHAR){
> + return false;
> + }
>// Look at the next character
>wildcardSearchPos++;
> }
> **
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-475) RAMDirectory(Directory dir, boolean closeDir) constructor uses memory inefficiently.
[ http://issues.apache.org/jira/browse/LUCENE-475?page=comments#action_12359083 ] Bernhard Messer commented on LUCENE-475: I like the patch and find it very helpful if one tries to load larger indices into RAMDirectory. Hoss Man, why do you would like to have a new constructor to adjust the internal buffer size. I do not see any reason to make the buffersize configurable from outside. The tests i made with different sizes didn't show any difference on performace or disk usage. The new implementation would be similar to BufferedIndexOutput where the internal buffer size couldn't be changed either. Do i miss something ? > RAMDirectory(Directory dir, boolean closeDir) constructor uses memory > inefficiently. > -- > > Key: LUCENE-475 > URL: http://issues.apache.org/jira/browse/LUCENE-475 > Project: Lucene - Java > Type: Improvement > Components: Store > Reporter: Volodymyr Bychkoviak > Attachments: RamDirectory.diff > > recently I found that RAMDirectory(Directory dir, boolean closeDir) > constructor uses memory inefficiently. > files from source index are read entirely intro memory as single byte array > which is after all is thrown away. And if I want to load my 200M optimized, > compound format index to memory for faster search I should give JVM at least > 400Mb memory limit. For larger indexes this can be an issue. > I've attached patch how to solve this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LUCENE-475) RAMDirectory(Directory dir, boolean closeDir) constructor uses memory inefficiently.
[ http://issues.apache.org/jira/browse/LUCENE-475?page=all ] Bernhard Messer closed LUCENE-475: -- Fix Version: CVS Nightly - Specify date in submission Resolution: Fixed Volodymyr, thanks for the fix. It's reviewed and commited. Bernhard > RAMDirectory(Directory dir, boolean closeDir) constructor uses memory > inefficiently. > -- > > Key: LUCENE-475 > URL: http://issues.apache.org/jira/browse/LUCENE-475 > Project: Lucene - Java > Type: Improvement > Components: Store > Reporter: Volodymyr Bychkoviak > Fix For: CVS Nightly - Specify date in submission > Attachments: RamDirectory.diff, RamDirectory2.diff > > recently I found that RAMDirectory(Directory dir, boolean closeDir) > constructor uses memory inefficiently. > files from source index are read entirely intro memory as single byte array > which is after all is thrown away. And if I want to load my 200M optimized, > compound format index to memory for faster search I should give JVM at least > 400Mb memory limit. For larger indexes this can be an issue. > I've attached patch how to solve this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-758) IndexReader.isCurrent fails when using two IndexReaders
IndexReader.isCurrent fails when using two IndexReaders
---
Key: LUCENE-758
URL: http://issues.apache.org/jira/browse/LUCENE-758
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 2.0.1
Environment: Operating System: other
Platform: other
Reporter: Bernhard Messer
Priority: Minor
there is a problem in IndexReader.isCurrent() if using two reader instances
where one of them is based on a RAMDirectory. If there is an index and we open
two IndexReaders where one is based on a FSDirectory and the other is based on
a RAMDirectory, the IndexReader using the RAMDirectory does not recognize when
the underlaying index has changed. The method IndexReader.isCurrent() always
returns true. The testcase below shows the problem.
I did not find an ideal solution to solve the problem. I think the best way
would be to change the IndexReader.isCurrent() implementation from:
public boolean isCurrent() throws IOException {
return SegmentInfos.readCurrentVersion(directory) ==
segmentInfos.getVersion();
}
to something like:
public boolean isCurrent() throws IOException {
return directory.readCurrentVersion() == segmentInfos.getVersion();
}
As far as i can see this would work for FS- and RAMDirectory. But then the
implementing Directory classes have to know about "segment" files and there
formating details.
What do others think ?
/**
* additional testcase for IndexReaderTest to show the problem when using two
different Readers
*/
public void testIsCurrentWithCombined() throws Exception {
String tempDir = System.getProperty("tempDir");
if (tempDir == null)
throw new IOException("tempDir undefined, cannot run test");
File indexDir = new File(tempDir, "lucenetestiscurrent");
Directory fsStore = FSDirectory.getDirectory(indexDir, true);
IndexWriter writer = new IndexWriter(fsStore, new SimpleAnalyzer(), true);
addDocumentWithFields(writer);
writer.close();
IndexReader reader1 = IndexReader.open(fsStore);
IndexReader reader2 = IndexReader.open(new RAMDirectory(fsStore));
assertTrue(reader1.isCurrent());
assertTrue(reader2.isCurrent());
reader1.deleteDocument(0);
reader1.close();
// BUG: reader based on the RAMDirectory does not recognize the index
change.
assertFalse(reader2.isCurrent());
reader2.close();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
