You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2009/06/01 15:50:07 UTC
[jira] Created: (LUCENE-1672) Deprecate all String/File ctors/opens
in IndexReader/IndexWriter/IndexSearcher
Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
------------------------------------------------------------------------------
Key: LUCENE-1672
URL: https://issues.apache.org/jira/browse/LUCENE-1672
Project: Lucene - Java
Issue Type: Task
Affects Versions: 2.9
Reporter: Uwe Schindler
Fix For: 2.9
During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715085#action_12715085 ]
Shai Erera commented on LUCENE-1672:
------------------------------------
Can we stick with just a File argument, no String?
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1672) Deprecate all String/File ctors/opens
in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-1672:
----------------------------------
Attachment: LUCENE-1672.patch
Here is a first patch, deprecating all usages of File/String to specify a directory. I am not sure, if I hit all, if somebody knows another one, tell it.
This patch also replaces FSDirectory.getDirectory() by FSDirectory.open() for all non-deprecated methods. The deprecated IndexReader/IndexWriter and so on methods still use FSDir.getDirectory because they sometimes depend on refCounting (which is wrong). This is a bug related to LUCENE-1453.
I will post a later patch that fixes this by wrapping all IndexReaders instantiated by File/String with a FilterIndexReader that manages the closing of the underlying directory. All closeDirectory/closeDir pass-throughs everywhere can then be removed.
This also fixes a small bug in IndexModifier to close the directory on close() when dir was given as File/String.
I also removed File/String in the segment file finder (non-public API).
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1672) Deprecate all String/File ctors/opens
in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-1672:
----------------------------------
Attachment: LUCENE-1672.patch
Updated patch merged with Mike's last commit.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715949#action_12715949 ]
Uwe Schindler commented on LUCENE-1672:
---------------------------------------
Nice. And DirectoryIR/MSR still have this Flag, but reopening a MSR always returns a MSR again (even if it only consists of one segment)?
If this is so, I wait for your issue to be closed and then rework here.
To test, if the closedir (LUCENE-1453) issue is correctly solved, try to replace FSDir.getDirectory by FSDir.open(). in IndexReader.open() taking File/String. If TestIndexReaderReopen then passes (even with different random seeds, so run test multiple times) always, it is really fixed.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Earwin Burrfoot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715944#action_12715944 ]
Earwin Burrfoot commented on LUCENE-1672:
-----------------------------------------
bq. I will later try to solve this problem with the closeDir inside the different IndexReaders (but maybe Earwin has done it already in LUCENE-1651)
My issue removes closeDir from SegmentReader, as it cannot 'own' a directory anymore. MSR-to-be-DirectoryReader still has this flag.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-1672) Deprecate all String/File ctors/opens
in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-1672:
----------------------------------
Attachment: LUCENE-1672.patch
Updated patch. I commit shortly and close this issue.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715913#action_12715913 ]
Michael McCandless commented on LUCENE-1672:
--------------------------------------------
Patch looks good Uwe! You don't really need to deprecate methods in IndexModifier, since the whole class is deprecated.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Assigned: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler reassigned LUCENE-1672:
-------------------------------------
Assignee: Uwe Schindler
Mike: Thanks for committing LUCENE-1651!
I will update this patch and commit sometime this evening.
Before I do this, I will also check, if now reopen() works correctly when replacing all FSDir.getDir() by FSDir.open().
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Closed: (LUCENE-1672) Deprecate all String/File ctors/opens
in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler closed LUCENE-1672.
---------------------------------
Resolution: Fixed
Fixed revision 782469.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Earwin Burrfoot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715093#action_12715093 ]
Earwin Burrfoot commented on LUCENE-1672:
-----------------------------------------
Yahoo! I was going to create the same issue :)
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Earwin Burrfoot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715962#action_12715962 ]
Earwin Burrfoot commented on LUCENE-1672:
-----------------------------------------
bq. And DirectoryIR/MSR still have this Flag, but reopening a MSR always returns a MSR again (even if it only consists of one segment)?
Exactly.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Shai Erera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715092#action_12715092 ]
Shai Erera commented on LUCENE-1672:
------------------------------------
Ooops, my fault. I didn't read the subject and description carefully.
Yep, sticking w/ Dir ctorsshould definitely simplify things.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717060#action_12717060 ]
Michael McCandless commented on LUCENE-1672:
--------------------------------------------
Excellent!
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1672) Deprecate all
String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715936#action_12715936 ]
Uwe Schindler edited comment on LUCENE-1672 at 6/3/09 7:26 AM:
---------------------------------------------------------------
With IndexModifier, you are right. I was just adding this closeDir stuff (which is missing here and is a real bug) and deprecated these methods. In the JavaDocs every method is deprecated automatically, so I do not need to do it specifically.
I will later try to solve this problem with the closeDir inside the different IndexReaders (but maybe Earwin has done it already in LUCENE-1651) with a filtered IndexReader returned by the open() methods taking a String/File. I can then revert/remove all these closeDir parameters/members.
was (Author: thetaphi):
With IndexModifier, you are right. I was just adding this closeDir stuff (which is missing here and is a real bug) and deprecated these methods. In the JavaDocs every method is deprecated automatically, so I do not need to do it specifically.
I will later try to solve this problem with the closeDir inside the different IndexWriters (but maybe Earwin has done it already in LUCENE-1651) with a filtered IndexReader returned by the open() methods taking a String/File. I can then revert/remove all these closeDir parameters/members.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715936#action_12715936 ]
Uwe Schindler commented on LUCENE-1672:
---------------------------------------
With IndexModifier, you are right. I was just adding this closeDir stuff (which is missing here and is a real bug) and deprecated these methods. In the JavaDocs every method is deprecated automatically, so I do not need to do it specifically.
I will later try to solve this problem with the closeDir inside the different IndexWriters (but maybe Earwin has done it already in LUCENE-1651) with a filtered IndexReader returned by the open() methods taking a String/File. I can then revert/remove all these closeDir parameters/members.
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1672.patch, LUCENE-1672.patch
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1672) Deprecate all String/File
ctors/opens in IndexReader/IndexWriter/IndexSearcher
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715089#action_12715089 ]
Uwe Schindler commented on LUCENE-1672:
---------------------------------------
But the File argument has the same problem with passing all these closeDirectory arguments around. If we wrap this using this FilterIndexReader, ok, but as discussed yesterday, I would prefer to simply only allow Directory as input parameter and leave specifying the dir impl to the user. Automatically use FSDir.open() is also not the best choose, because then user ask again of java-user (how to specify another impl and so on).
For the user it is just a little bit more code and the additional close() call (which can normally left out for standard directories...)
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should not use them anymore. As the user is now free to choose the correct directory implementation using direct instantiation or using FSDir.open() he should no longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co. that simply take path names as String or File and always instantiate the Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime reopen() closes the directory (as far as I see, when a SegmentReader changes to a MultiSegmentReader and/or deletes apply). This is hard to track. In Lucene 3.0 we then can remove the whole bunch of closeDirectory parameters/fields in these classes and simply do not care anymore about closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453 correctly, an additional idea would be to change these factories that take the File/String to return the IndexReader wrapped by a FilteredIndexReader, that keeps track on closing the underlying directory after close and reopen. This is simplier than passing this boolean between different DirectoryIndexReader instances. The small performance impact by wrapping with FilterIndexReader should not be so bad, because the method is deprecated and we can state, that it is better to user the factory method with Directory parameter.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org