[
https://issues.apache.org/jira/browse/LUCENE-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262289#comment-14262289
]
Robert Muir commented on LUCENE-6146:
-------------------------------------
Sorry, i am just unhappy thinking about optimizations when we have these bugs
in the directory API.
I am ok with a one-liner to warn there. But honestly this method is still not
going to work well for "subclassing" anyway. Its almost pointless to optimize
the impls because something like a FilterDirectory will easily wipe away the
optimization.
An alternative solution would be a method on Directory to optionally return a
Path for a filename, or some abstraction like a "handle", but i hate
overengineering it.
> Directory.copy -> Directory.copyFrom
> ------------------------------------
>
> Key: LUCENE-6146
> URL: https://issues.apache.org/jira/browse/LUCENE-6146
> Project: Lucene - Core
> Issue Type: Task
> Components: core/store
> Reporter: Robert Muir
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6146.patch
>
>
> Spinoff of LUCENE-4746.
> This method is currently:
> {code}
> copy(Directory to, String src, String dest, IOContext context)
> {code}
> But it would be better to restructure this so the destination directory is
> the one actually being changed by the operation:
> {code}
> copyFrom(Directory from, String src, String dest, IOContext context)
> {code}
> Besides fixing the order to make sense, adding it to the name might help
> prevent bugs like the current TrackingDirectoryWrapper impl (used by
> IndexWriter to track what files are used):
> {code}
> public void copy(Directory to, String src, String dest, IOContext context)
> throws IOException {
> createdFileNames.add(dest); // BUG!
> in.copy(to, src, dest, context);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
