-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't register any database changes to the indexer while dropping a file #8334
Conversation
} | ||
case MOVE -> { | ||
LOGGER.debug("Mode MOVE"); // alt on win | ||
libraryTab.getIndexingTaskManager().setBlockingNewTasks(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why this blocking shouldn't be added directly to the importHandler
(or linker)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all users of importHandler have access to the IndexingTaskManager unfortunately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mhh, do you have an example where this occurs? The whole linker/import handler stuff arose from the fact that there were many very similarly-looking code blocks scattered around the code base, that all handled imports in a similar but same way. Was a huge headache, so I would like not to introduce special handling in certain situations again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that sounds like a good reason to do it directly in the import handler.
The PreviewPanel was my concern, but I passed it along and made it work.
LOGGER.debug("Mode MOVE"); // alt on win | ||
libraryTab.getIndexingTaskManager().setBlockingNewTasks(true); | ||
importHandler.getLinker().moveFilesToFileDirAndAddToEntry(entry, files); | ||
libraryTab.getIndexingTaskManager().setBlockingNewTasks(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of this setBlockingNewTasks(true/false)
pattern, I would suggest to use the try resource solution: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html, i.e.
try (libraryTab.getIndexingTaskManager().blockingNewTasks()) {
importHandler.getLinker().moveFilesToFileDirAndAddToEntry(entry, files);
}
In this way, you make sure that the setBlockingNewTasks(false)
is always executed, even in case there is a (runtime) exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if I understand that right I would need to make the blocking() method of IndexingTaskManager return a 'closable', right? I could define that as a lambda that resets the flag.
Or is there a better way you are hinting at?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried it and it was easy enough - so I think I got what you meant. Thanks for the hint!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but I didn't deep look so would prefer if someone else also looks over it.
Thanks for your continued work on making the indexing better and better!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two comments.
@@ -143,11 +143,11 @@ public EntryEditor(LibraryTab libraryTab, ExternalFileTypes externalFileTypes) { | |||
switch (event.getTransferMode()) { | |||
case COPY -> { | |||
LOGGER.debug("Mode COPY"); | |||
fileLinker.copyFilesToFileDirAndAddToEntry(entry, files); | |||
fileLinker.copyFilesToFileDirAndAddToEntry(entry, files, libraryTab.getIndexingTaskManager()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you somehow inverse the dependency on libraryTab here (maybe injecting it in the constructor) ?
@@ -383,11 +388,11 @@ private void handleOnDragDropped(TableRow<BibEntryTableViewModel> row, BibEntryT | |||
} | |||
case MOVE -> { | |||
LOGGER.debug("Mode MOVE"); // alt on win | |||
importHandler.getLinker().moveFilesToFileDirAndAddToEntry(entry, files); | |||
importHandler.getLinker().moveFilesToFileDirAndAddToEntry(entry, files, libraryTab.getIndexingTaskManager()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IoC here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having the IndexingTaskManager in ImportHandler would require a lot of refactoring and passing along the IndexingTaskManager in many files. I would really like to avoid that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I agree, it's probably better to fix the bug now.
But sooner or later we have to deal with that. 😅
Great! Before merging I would like to wait for @koppor to confirm the issue is fixed for him as well (as he is on windows). |
I'm going to merge this now, as it's good to have it in the release |
* upstream/main: Don't register any database changes to the indexer while dropping a file (#8334) Fix ACM fetcher (#8338) Squashed 'buildres/csl/csl-styles/' changes from 3bb4b5f..60bf7d5 Exception shouldn't happen when pasting an entry with a publication date-range of form yyyy-yyyy (#8247) Refactor Sidepane logic (#8202) New translations JabRef_en.properties (Japanese) (#8331) Bump bcprov-jdk15on from 1.69 to 1.70 (#8333) Update Controlsfx to 11.1.1 (#8330) Update citeproc (#8329) Bump classgraph from 4.8.137 to 4.8.138 (#8327) Bump junit-platform-launcher from 1.8.1 to 1.8.2 (#8326) Remove outdated gradle deps check (#8324) Bump junit-jupiter from 5.8.1 to 5.8.2 (#8325) Bump libreoffice from 7.2.2 to 7.2.3 (#8328) Remove outdated ignores
Certainly won't hurt. If @koppor still has an isse we can open a new Issue. |
* upstream/main: (46 commits) New Crowdin updates (#8349) Bump pdfbox from 2.0.24 to 2.0.25 (#8345) Bump fontbox from 2.0.24 to 2.0.25 (#8348) Bump xmlunit-core from 2.8.3 to 2.8.4 (#8347) Bump tika-core from 2.1.0 to 2.2.0 (#8346) Added missing executable bindings to various commands (#8342) Update Gradle Wrapper from 7.3.1 to 7.3.2. (#8343) Fix issues with writing metadata to pdfs (#8332) add tinylog test (#8339) Tinylog (#8226) Don't register any database changes to the indexer while dropping a file (#8334) Fix ACM fetcher (#8338) Squashed 'buildres/csl/csl-styles/' changes from 3bb4b5f..60bf7d5 Exception shouldn't happen when pasting an entry with a publication date-range of form yyyy-yyyy (#8247) Refactor Sidepane logic (#8202) New translations JabRef_en.properties (Japanese) (#8331) Bump bcprov-jdk15on from 1.69 to 1.70 (#8333) Update Controlsfx to 11.1.1 (#8330) Update citeproc (#8329) Bump classgraph from 4.8.137 to 4.8.138 (#8327) ... # Conflicts: # build.gradle
There was a problem that involved the Indexer and Drag&Drop operations while having auto-file-move/rename enabled.
When dropping a File onto an entry, JabRef links that file to the entry and moves and renames the files according to the set preferences. It was possible for this to happen while the PDFIndexer was running. This could lead to:
This was solved by not allowing for any files to be added to the indexer during drag&drop operations.
Fixes #8182.
CHANGELOG.md
described in a way that is understandable for the average user (if applicable)