Jabref: timestamp is not updated when entry changes

[ilippert]

JabRef 4.0.0-dev--snapshot--2017-05-01--master--fcac52707
Linux 4.10.12-200.fc25.x86_64 amd64
Java 1.8.0_131

as noted in the opening post of #2808, in my version the timestamp is not updated. even though I configured it to be updated (and it worked in recent versions)

The user experience is related to #2812: to some degree the changed timestamp is simply not immediately shown.

However, for some entries (and I do not recognise a pattern yet) the timestamp is not updated at all (i.e. even no change of timestamp after change and save and restart of jabref.

[ayanzunaid]

I would like to work on this issue.

[koppor]

@tobiasdiez I think that it makes sense that @ayanzunaid works on that. I suppose, the code has to be adapted to use our eventing system?

[Siedlerchr]

I took a quick look yesterday and it seems that only the file timestamp is somehow updated (according to the config options), and not the entry timestamp in the main table

[tobiasdiez]

@ayanzunaid you are of course welcome to work on it. The root of the issue is probably that the doUpdateTimestamp method is no longer called with the recent changes in the entry editor.
Moreover, I think it would make sense that this method is extracted from the entry editor and implemented as a change listener for the whole database (so that also changes via e.g. the cleanup operation) trigger an update of the timestamp.

Feel free to ask for further help if you get stuck at some point.

[ferg35]

hello. i want to help with this issue, but cant find where recent changes in the entry editor saves.
is there any listener for this? where would you advise me to watch? (sorry for my english)

[tobiasdiez]

@ferg35: Nice to hear!

The EntryChangedEvent is issued after an entry changed (see here for a list of uses of this class). You can subscribe to these events similar to the SearchAutoCompleteListener. As I said above, I wouldn't tie the update to the entry editor since entries can be changed also on other means (e.g. cleanup).

[Siedlerchr]

The problem is with the EntryChanged event, it is fired even when you just
enter one new character or delete one in one entry.
So the frequency is very high

2017-06-27 11:50 GMT+02:00 Tobias Diez [e-mail]:

@ferg35 https://github.com/ferg35: Nice to hear!

The EntryChangedEvent is issued after an entry changed (see here. You
can subscribe to these events similar to the SearchAutoCompleteListener
https://github.com/JabRef/jabref/blob/52b887dd1b6a11f3a2d02eb592a718fe575c6962/src/main/java/org/jabref/gui/BasePanel.java#L2106.
As I said above, I wouldn't tie the update to the entry editor since
entries can be changed also on other means (e.g. cleanup).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JabRef/jabref/issues/2810#issuecomment-311310104, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AATi5CB122XTPQBWP6WRkGaH9egdBo_4ks5sINB_gaJpZM4NNTIO
.

[lhoff94]

hi
it seems like that this Issue is still not fixed. I assume that there is currently nobody working on it right now. If thats the case i'd like to work on that Issue together with @tobous.

[koppor]

@bimini94 Yes, please. Go ahead. - I think, the EntryChangedEvent is not fired that often now. I think @lenhard did something there in the context of autosave.

[tobous]

We had a look at the problem. The needed functionality seems to already be present in EntryEditor.StoreFieldAction#updateTimeStamp(UndoableEdit). The problem is that the class EntryEditor.StoreFieldAction is never used. Furthermore, the EntryEditor is no longer registering the annotated "@Subscribe" methods after commit 42ea6bc (which is part of a fix for issue #3366).

We would like to follow the given suggestions and create a listener on EntryChangedEvent which is listening on the whole database.
We still have some questions regarding the implementation of the listener:

• Our current plan is to implement the listener as an inner class of BasePanel.java and then call "this.getDatabase().registerListener(...)" with our listener. This would follow the given example of the SearchAutoCompleteListener.
  Would this be acceptable or should our listener be contained in a different class or be registered on a different EventBus?

• Our fix would basically follow the solution implemented in EntryEditor.StoreFieldAction#updateTimeStamp(UndoableEdit). In this method, everything is handled as an UndoableEdit. Is the usage of an UndoableEdit important for the setting of the timestamp?
  Our current guess would be that it is only an UndoableEdit in the existing implementation so that it can be reversed if the change that caused the event is reversed. This would however not apply at a database level as there are different causes that are not all undoable. Or should our implementation include a check to make our change of the timestamp undo-able if the change that caused the event is undoable?

Furthermore, we would like to address the frequency of fired events: During our tests, the EntryChangedEvent was still fired with every added (or removed) character. We haven't seen any events triggered in any other context (for example by autosaves). But we did not do very extensive testing, so this doesn't have to mean much.

[tobous]

Created a WIP pull request under the above mentioned assumptions.

We have some problems with our new tests being dependent on JabRefPreferences, which is not allowed according to the test TestArchitectureTests#testsAreIndependent(). A more detailed description is given as part of the pull request.

[tobiasdiez]

This should be fixed in the latest development version thanks to a fix by @tobous. Could you please check the build from http://builds.jabref.org/master/. Thanks!

[ilippert]

Yeah, it works! Thanks a lot!!!