lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <>
Subject [jira] Commented: (LUCENE-2818) abort() method for IndexOutput
Date Sat, 18 Dec 2010 10:02:01 GMT


Earwin Burrfoot commented on LUCENE-2818:

bq. Can abort() have a default impl in IndexOutput, such as close() followed by deleteFile()
maybe? If so, then it won't break anything.
It can't. To call deleteFile you need both a reference to papa-Directory and a name of the
file this IO writes to. Abstract IO class has neither. If we add them, they have to be passed
to a new constructor, and that's an API break ;)

bq. Would abort() on Directory fit better? E.g., it can abort all currently open and modified
files, instead of the caller calling abort() on each IndexOutput? Are you thinking of a case
where a write failed, and the caller would call abort() immediately, instead of some higher-level
code? If so, would rollback() be a better name?
Oh, no, no. No way. I don't want to push someone else's responsibility on Directory. This
abort() is merely a shortcut.

Let's go with a usage example:
Here's with LUCENE-2814 applied (skipping irrelevant parts) -
Now, the same, with abort() -

> abort() method for IndexOutput
> ------------------------------
>                 Key: LUCENE-2818
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Earwin Burrfoot
> I'd like to see abort() method on IndexOutput that silently (no exceptions) closes IO
and then does silent papaDir.deleteFile(this.fileName()).
> This will simplify a bunch of error recovery code for IndexWriter and friends, but constitutes
an API backcompat break.
> What do you think?

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:
For additional commands, e-mail:

View raw message