-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Discard attribute changed callbacks during graph loading #2598
base: develop
Are you sure you want to change the base?
Conversation
9acd7f8
to
db5dc3b
Compare
Provide a way to control how to handle node compatibility issues when loading a Graph with the `strictCompatibility` parameter. Introduce a new error type, GraphCompatibilityError, to be raised when loading a Graph with compatibility issues with strictCompatibility enabled.
Update tests that should fail if nodes are loaded as CompatibilityNodes (resulting in false positives).
db5dc3b
to
61d3590
Compare
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.
Did a test around this, the current changes did solve part of the problem which was loading a graph with no onAttrChanged
callbacks triggered and no unwanted CompatibilityIssues
raised.
My tests involved having a ChoiceParam Combo Box getting values populated in an onAttrChanged function,
and when the graph is saved and loaded back, the last value on the ChoiceParam is retained, but is shown in Red or invalid in the GUI, as the value is no longer part of the default values on the ChoiceParam which are loaded when the node gets deserialised.
Heart of the issue comes from the fact, we're not serialising the current set of values on the param in the graph file to be able to load them back upon loading.
Guessing this issue came into being with the introduction of allowing dynamic values on the ChoiceParam, as now the choiceParam can get updated values during any method calls.
Thinking about the best way would be to serialise values from such params.
Graph: The loaded Graph instance. | ||
|
||
Raises: | ||
GraphCompatibilityError: If the Graph has node compatibility issues and `strictCompatibility` is 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.
GraphCompatibilityError: If the Graph has node compatibility issues and `strictCompatibility` is False. | |
GraphCompatibilityError: If the Graph has node compatibility issues and `strictCompatibility` is True. |
I believe this should be True for the graph to raise an Error ?
To be able to reproduce what I did, please use the nodes from https://gist.github.com/waaake/d96a5ae6bd8f00c4a7ee0f99cd6a9242 Steps:
|
Description
Ensure attribute changed callbacks are not triggered on graph loading.
When loading a graph, we expect nodes to be deserialized in the exact state they were saved.
Attribute callbacks may modify attribute values and impact the UID of the nodes.
This was leading to UID compatibility conflicts on file opening, for Graph containing Nodes using such mechanisms.
Features list
Implementation remarks
While this behavior was covered by a test, it turned out to be a false positive.
The error was hidden behind the fact that the tested Node was actually UID conflicting due to the callback, and swapped to a Compatibility Node. Therefore, attribute values were restored to the serialized ones, with expected values.
The introduction of the "strictCompatibility" mode allows to test this behavior more efficiently.