More fixes for broken updates #3217
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fb80c18 to
3ff9c23
Compare
Instead of handling diagram updates when the views need a rerender (the old behavior), we update all diagrams before a transaction is committed. This ensures that diagram updates happen within the context of a transaction.
3ff9c23 to
86521cd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Type
What kind of change does this PR introduce?
Follow up of #3205.
What is the current behavior?
The new update model is still not fool proof. Mostly updates coming from changes in the model are not always reflected in the diagrams.
The main issue is that I'd like to batch updates, but those update do have to happen within the context of the current transaction. Ergo, they can not happen completely asynchronous (as was the case previously).
Just requesting an update is not enough.
This is now solved by updating directly after an update request is done. This has the possible risk of doing double work. However, it's our only guarantee at the moment to make sure the diagrams are up to date.
Issue Number: N/A
What is the new behavior?
The
request_update()methods still schedule a diagram item for an update. The update now happens when a transaction is committed.To ensure that the transaction is not closed directly, the Undo Manager schedules a new event to close the commit.
This only works when working with diagrams interactively. If diagrams are changed programmatically,
Diagram.update()needs to be called explictly.Does this PR introduce a breaking change?
Other information