Skip to content

Conversation

@saintentropy
Copy link
Contributor

@saintentropy saintentropy commented Feb 25, 2018

Purpose

This PR allows for Nodes that are derived from NodeModel and utilize tracing mechanism to have binding data serialized to the json file.

Declarations

Check these if you believe they are true

  • The code base 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.

Reviewers

@mjkkirschner

FYIs

@sm6srw @nonoesp

ws.Nodes.Where(
n => n is DSFunction || n is DSVarArgFunction || n is CodeBlockNodeModel || n is Function)
n => n is DSFunction || n is DSVarArgFunction || n is CodeBlockNodeModel || n is Function ||
n.GetType().GetCustomAttributes(typeof(DynamoServices.RegisterForTraceAttribute),false).Length>0 )
Copy link
Member

Choose a reason for hiding this comment

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

maybe .Any() would be more clear to - also, I wouldn't mind if this was a helper function. - we may already have it around in utils.

Copy link
Member

@mjkkirschner mjkkirschner Feb 25, 2018

Choose a reason for hiding this comment

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

is there any performance implication to adding this check to every node in the graph on save? - how long does it take per node?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good points. I will look for a preexisting utility. As for perf I am not sure but I will check. I suspect it can't be too much more as we are selecting and short-circuiting on every zero touch node. There can't be too many nodes that don't fall under the first four conditions. Let me look though if there is a faster way to test for the attribute.

@mjkkirschner
Copy link
Member

please add a test - I know the change is small, but the behavioral change is not small.

We should have a test that checks serialization and deserialization works.

@mjkkirschner
Copy link
Member

@saintentropy maybe you could also document that the register for trace attribute is to be used only on nodeModel types.

@mjkkirschner
Copy link
Member

@saintentropy another thought. What happens for all our revit nodes where devs have been using the [registerForTrace] attr for no reason for 3 years. It was harmless before - does it cause any unwanted behavior now?

@saintentropy
Copy link
Contributor Author

I am working on the tests and I will also examine the implications for the Revit nodes. Still seems like we are adding additional cover to how serialization is aware of trace utilization within the node and should not have material impact. If anyone had ever made a NodeModel derived node that utilized trace then we would have already addressed this

@ramramps
Copy link
Collaborator

@saintentropy I understand the intent here. But can you point the JIRA task and the Acceptance criteria? That would help someone in the future if there are any issues.

@mjkkirschner
Copy link
Member

@saintentropy I'm not really sure what your last comment means. My point is exactly that it appears NodeModel nodes never supported trace and so that is a large change in behavior. To make sure that this behavior is encoded somewhere a test is required.

@saintentropy
Copy link
Contributor Author

@benglin @ke-yu @aparajit-pratap Any reason that we specifically excluded NodeModel derived nodes from having tracing data serialized to the Dyn?

@aparajit-pratap
Copy link
Contributor

@kronz @saintentropy I can't think of any specific reason why we left out NodeModel nodes from serializing trace data. I don't think there was any need until now. We have been adding support for trace to node types incrementally. At one point of time when we realized that element binding wasn't working for custom nodes, only then did we decide to add support for custom nodes.

@benglin
Copy link
Contributor

benglin commented Feb 28, 2018

@saintentropy I have been staring at this and my PR for a long while. Let me get into the office and have a word with @ke-yu, hopefully I'll have a less random answer for you later.

@ke-yu
Copy link
Contributor

ke-yu commented Feb 28, 2018

@saintentropy It has been a while, I don't remember all details...Tracing data is to do element binding, i.e., associating elements with the node that creates these elements so that if the node is re-executed, the original elements should be disposed properly.

Tracing data is a dictionary updated by DesignScript virtual machine when the virtual machine is executing a function (tracing data format looks like "<unique_ids_to_that_function, element ids>"). Not all NodeModels get compiled to functions, that's why we only include DSFunction, Function, DSVarArgFunction and CodeBlockNode, and other nodes that have that attribute.

But, as most of other nodes only generate empty tracing data, I think you could enable tracing data on all nodes.

@saintentropy saintentropy changed the title WIP: Add RegisterFroTrace attribute as a trigger in Json serialization WIP: Add RegisterForTrace attribute as a trigger in Json serialization Mar 1, 2018
@jnealb
Copy link
Collaborator

jnealb commented Mar 8, 2018

@saintentropy @mjkkirschner Is there a JIRA task for this?

@saintentropy saintentropy added DNM Do not merge. For PRs. and removed WIP labels Mar 9, 2018
@saintentropy saintentropy self-assigned this Mar 9, 2018
@saintentropy saintentropy changed the title WIP: Add RegisterForTrace attribute as a trigger in Json serialization Add RegisterForTrace attribute as alternate trigger in Json serialization Mar 9, 2018
@saintentropy
Copy link
Contributor Author

@saintentropy saintentropy reopened this Mar 9, 2018
@jnealb
Copy link
Collaborator

jnealb commented Mar 9, 2018

@saintentropy Thanks

@saintentropy saintentropy added PTAL Please Take A Look 👀 and removed DNM Do not merge. For PRs. labels Mar 13, 2018
@saintentropy
Copy link
Contributor Author

Ok @mjkkirschner. Now what do you think?

@ramramps
Copy link
Collaborator

@saintentropy can it wait until friday? I don't see any major change coming, but in case...

@saintentropy
Copy link
Contributor Author

That is fine :-)

@saintentropy
Copy link
Contributor Author

saintentropy commented Mar 22, 2018

@mjkkirschner @QilongTang @kronz Ping. Really need to get this into master

@ramramps
Copy link
Collaborator

@saintentropy LGTM.

@saintentropy
Copy link
Contributor Author

Ok I am merging now

@saintentropy saintentropy merged commit 3724e5a into DynamoDS:master Mar 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PTAL Please Take A Look 👀

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants