public final class ChangedFilesCollector
extends java.lang.Object
AsyncFileListener.ChangeApplier
Constructor and Description |
---|
ChangedFilesCollector() |
Modifier and Type | Method and Description |
---|---|
protected void |
buildIndicesForFileRecursively(VirtualFile file,
boolean contentChange) |
boolean |
containsFileId(int fileId) |
protected void |
iterateIndexableFiles(VirtualFile file,
ContentIterator iterator) |
AsyncFileListener.ChangeApplier |
prepareChange(java.util.List<? extends VFileEvent> events)
Called (possibly on a background thread) when a batch of VFS events is ready to be fired.
|
void |
waitForVfsEventsExecuted(long timeout,
java.util.concurrent.TimeUnit unit) |
protected void buildIndicesForFileRecursively(VirtualFile file, boolean contentChange)
protected void iterateIndexableFiles(VirtualFile file, ContentIterator iterator)
public boolean containsFileId(int fileId)
public AsyncFileListener.ChangeApplier prepareChange(java.util.List<? extends VFileEvent> events)
AsyncFileListener
ProgressManager.checkCanceled()
often enough.
Note that this listener can only observe the state of the system before VFS events, and so
it can't work with anything that would be after them, e.g. there will be no file in
VFileCreateEvent
, FileIndexFacade
won't know anything about the updated state after VFS change, and so on.
Note that the events posted passed might differ from the ones passed into BulkFileListener
.
In particular, there may occasionally be several events about the same file (e.g deletion and then creation, or creation and
then deletion of the file's parent). Hence the order of events is significant. Implementations should be prepared to such situations.
prepareChange
in interface AsyncFileListener
public void waitForVfsEventsExecuted(long timeout, java.util.concurrent.TimeUnit unit) throws java.lang.Exception
java.lang.Exception