Skip to content
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

Fixing NodewView serializationn properties #13663

Merged
merged 5 commits into from
Jan 18, 2023
Merged

Fixing NodewView serializationn properties #13663

merged 5 commits into from
Jan 18, 2023

Conversation

jesusalvino
Copy link
Contributor

Purpose

Fix the bug https://jira.autodesk.com/browse/DYN-5446-serializing-dyn-file

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated

Reviewers

@QilongTang

FYIs

@RobertGlobant20 @filipeotero

@jesusalvino
Copy link
Contributor Author

jesusalvino commented Jan 7, 2023

imagen

imagen

@QilongTang
Copy link
Contributor

@jesusalvino Would you set the order for Node Model as well?

@jesusalvino
Copy link
Contributor Author

@jesusalvino Would you set the order for Node Model as well?

Done.

@QilongTang
Copy link
Contributor

@jesusalvino Would you share the reason why for NodeModel, you did not use the sequence number as identifier but chose a different implementation?

@jesusalvino
Copy link
Contributor Author

jesusalvino commented Jan 17, 2023

@jesusalvino Would you share the reason why for NodeModel, you did not use the sequence number as identifier but chose a different implementation?

Sure, because the NodeModel has serialized properties that are not directly mapped to its C# class, like the "ConcreteType" property and the NodeModel serialized properties could have extra properties based on the different kind of nodes like "Code" property or "InputValue", that's why the order of its serialized properties is handable after its json format, not in the tag order as part of its property in its C# Class like the NodeView, the order of serialization of the NodeModel property is centralized in the NodeModel.PropertiesSerializationOrder.

try
{
string metaNodesStartKey = "\"Nodes\": [\r\n ";
string metaNodesEndKey = "\r\n ]";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should use something cross platform using system environment new line or similar

{
string metaNodesStartKey = "\"Nodes\": [\r\n ";
string metaNodesEndKey = "\r\n ]";
int flatNodesStartIndex = metaContent.IndexOf(metaNodesStartKey) + metaNodesStartKey.Length;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code has the potential to be very slow, have you profiled the serialization performance of a very large graph before and after this change?

@@ -2265,6 +2265,11 @@ public virtual string PrintExpression()
return s;
}

public static List<string> PropertiesSerializationOrder()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this public?

{
List<string> metaProperties = new List<string>();

var rxKeyProperty = new Regex(keyProperty);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh boy.

@mjkkirschner
Copy link
Member

There is a lot of complexity in this new code, I did not finish reviewing it.

I am curious how much benefit there would be to simply using [JsonProperty(Order = n)] and avoiding the custom serialization ordering logic all together.

I'm also concerned about the potential performance impact - we should test it with various size graphs if we're going to proceed with this.

@jesusalvino
Copy link
Contributor Author

jesusalvino commented Jan 18, 2023

@QilongTang @mjkkirschner unfortunatelly I couldn't test the custom approach with a large .dyn file enclosed here , it stucks my Visual Studio when I try to debug it, so in order to keeping simple I switched to the order approach.

@QilongTang
Copy link
Contributor

@jesusalvino Glad you were able to solve this using simple order definition.

@QilongTang QilongTang merged commit 90987ac into DynamoDS:master Jan 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants